An adaptive correlation and interaction synchronization method and system for hedging business data

Abstract

This invention provides an adaptive correlation and interaction synchronization method and system for hedging business data, belonging to the field of data synchronization technology. The method includes: capturing parallel raw business data streams from a parallel hedging core data system via a parallel API interface; extracting parallel time-series material coding features and parallel time-series transaction timestamps, performing cross-system transaction business correlation matching to obtain P business process states of P related business chains; performing dynamic closed-loop updates of financial data; acquiring multi-source incremental changes captured by CDC through listening to an asynchronous message queue, identifying business process anomalies, and outputting business process update information; performing financial data anomaly rollback, and synchronizing the hedging business status. This invention solves the technical problem that existing data synchronization methods mostly rely on static data mapping rules, lack flexibility, are difficult to adapt to the dynamic changes of hedging business, resulting in low data integration efficiency and susceptibility to errors.

Description

Technical Field

[0001] This invention relates to the field of data synchronization technology, and more specifically to an adaptive correlation and interactive synchronization method and system for hedging business data. Background Technology

[0002] With the continuous development of hedging business, enterprises face massive amounts of data from multiple heterogeneous systems such as product delivery systems, futures trading systems, and financial systems. Existing data processing technologies have many shortcomings in integrating this multi-source heterogeneous data. On the one hand, traditional data synchronization methods mostly rely on static data mapping rules, lacking flexibility and struggling to adapt to dynamic changes in business rules, resulting in low data integration efficiency and a high risk of errors. On the other hand, existing technologies often use synchronous communication mechanisms during data interaction, which can easily lead to system congestion when the data volume is large or network latency is high, severely affecting data real-time performance and business response speed. These problems collectively lead to inconsistencies in data interaction between systems, thereby affecting the accuracy of hedging decisions and the effectiveness of risk management. Therefore, how to efficiently integrate multi-source heterogeneous data and ensure accurate data interaction and real-time synchronization between systems has become a critical issue that urgently needs to be addressed in current hedging operations. Summary of the Invention

[0003] This application provides an adaptive correlation and interaction synchronization method and system for hedging business data, aiming to solve the technical problem that most existing data synchronization methods rely on static data mapping rules, lack flexibility, are difficult to adapt to the dynamic changes of hedging business, and result in low data integration efficiency and easy errors.

[0004] The first aspect disclosed in this application provides an adaptive correlation and interaction synchronization method for hedging business data. The method includes: after a parallel API interface captures the parallel raw business data stream of a parallel hedging core data system based on a near real-time synchronization mechanism, the parallel raw business data stream is loaded into an intermediate data layer; the intermediate data layer receives and extracts the parallel time-series material coding features and parallel time-series transaction timestamps of the parallel raw business data stream, performs cross-system transaction business correlation matching, and obtains P business process states of P related business chains; based on the P business process states, the P related business chains are matched and sent to P intelligent financial system nodes for dynamic closed-loop updates of financial data; after obtaining multi-source incremental changes captured by CDC through listening to an asynchronous message queue, the multi-source incremental changes are loaded into the intermediate data layer based on the asynchronous message queue for business process anomaly identification, and business process update information is output; the business process update information is used to trigger a business status synchronization instruction to perform financial data anomaly rollback, and the hedging business status of the P intelligent financial system nodes is synchronized based on the rollback verification result.

[0005] The second aspect disclosed in this application provides an adaptive correlation and interactive synchronization system for hedging business data. This system is used in conjunction with the aforementioned adaptive correlation and interactive synchronization method for hedging business data. The adaptive correlation and interactive synchronization system for hedging business data includes: a data stream loading module, used to load the parallel raw business data stream of the parallel hedging core data system into an intermediate data layer after the parallel API interface captures the parallel raw business data stream based on a near real-time synchronization mechanism; and a business correlation matching module, used by the intermediate data layer to receive and extract the parallel time-series material coding features and parallel time-series transaction timestamps of the parallel raw business data stream, and to perform cross-system transaction business correlation matching. The system obtains the P business process states of P related business chains; a closed-loop update module is used to match and send the P related business chains to P smart financial system nodes for dynamic closed-loop updates of financial data based on the P business process states; an anomaly identification module is used to obtain multi-source incremental changes captured by CDC by listening to the asynchronous message queue, load the multi-source incremental changes to the intermediate data layer based on the asynchronous message queue for business process anomaly identification, and output business process update information; a status synchronization module is used to trigger a business status synchronization instruction to roll back the financial data anomaly using the business process update information, and synchronize the hedging business status of the P smart financial system nodes based on the rollback verification result.

[0006] One or more technical solutions provided in this application have at least the following beneficial effects:

[0007] The parallel API interface captures the raw business data stream of the parallel hedging core data system based on a near real-time synchronization mechanism and loads it into the intermediate data layer. This ensures rapid data updates and processing, avoids the latency issues in traditional batch processing, and improves the real-time performance of overall data synchronization. The intermediate data layer extracts parallel time-series material coding features and parallel time-series transaction timestamps to perform correlation matching on cross-system business data. This automated cross-system data correlation significantly reduces the cost and error rate of manual matching, improving the automation and intelligence level of business processes. The correlation-matched P business process states and P related business chains are sent to P smart finance system nodes to achieve dynamic closed-loop updates of financial data. Through this process, the financial system can update its own financial status based on real-time business data, ensuring the consistency between financial data and actual business processes. The system monitors multiple incremental changes to the source system database and loads these changes to the intermediate data layer via an asynchronous message queue. This allows the system to dynamically identify anomalies in business processes and update them promptly. This incremental data capture and processing method accurately identifies and processes changed data without completely refreshing all data, improving system efficiency and data accuracy. In the event of anomalies, the system triggers a rollback of financial data based on business process update information and synchronizes the hedging business status of the smart finance system nodes based on the rollback verification results. This mechanism ensures that financial data can be promptly restored to the correct state in the event of anomalies, avoiding the impact of data errors on financial reports and decisions. By verifying the rollback results, the rollback mechanism effectively avoids the serious impact of potential financial errors on the system, ensuring the integrity and consistency of financial data.

[0008] The above description is only an overview of the technical solution of this application. In order to better understand the technical means of this application and to implement it in accordance with the contents of the specification, and to make the above and other objects, features and advantages of this application more obvious and understandable, the following are specific embodiments of this application. Attached Figure Description

[0009] Figure 1 This is a schematic diagram of the adaptive correlation and interaction synchronization method for hedging business data provided in an embodiment of this application.

[0010] Figure 2 This is a schematic diagram of the adaptive correlation and interactive synchronization system structure for hedging business data provided in an embodiment of this application.

[0011] Explanation of reference numerals in the attached diagram: Data stream loading module 10, business association matching module 20, closed-loop update module 30, anomaly identification module 40, and status synchronization module 50. Detailed Implementation

[0012] This application provides an adaptive association and interaction synchronization method and system for hedging business data, which solves the technical problem that most existing data synchronization methods rely on static data mapping rules, lack flexibility, are difficult to adapt to the dynamic changes of hedging business, and result in low data integration efficiency and easy errors.

[0013] After introducing the basic principles of this application, various non-limiting embodiments of this application will be described in detail below with reference to the accompanying drawings. It should be understood that the specific embodiments described herein are merely illustrative of this application and are not intended to limit this application.

[0014] Example 1, as Figure 1 As shown in the embodiment of this application, an adaptive correlation and interaction synchronization method for hedging business data is provided, the method comprising:

[0015] After the parallel API interface captures the parallel raw business data stream of the parallel hedging core data system based on a near real-time synchronization mechanism, it loads the parallel raw business data stream into the intermediate data layer.

[0016] The parallel API interface is used to retrieve raw business data streams from multiple data sources and load them into the intermediate data layer. Parallel operation means that data fetching is performed concurrently, fetching data from different data sources simultaneously to reduce latency and improve data transmission efficiency. The near real-time synchronization mechanism means that data synchronization is not completely real-time, but rather occurs close to real-time. This mechanism relies on technologies such as scheduled tasks, incremental updates, or message queues to ensure rapid data updates. The parallel hedging core data system includes parallel product delivery systems, futures trading systems, and financial systems. The retrieved parallel raw business data streams include timestamp-aligned hedging basic business documents, futures transaction records, and settlement data. The intermediate data layer is used to cache, temporarily store, and process data. In this step, the parallel raw business data streams retrieved from various systems are first loaded into this intermediate data layer.

[0017] The intermediate data layer receives and extracts the parallel time-series material coding features and parallel time-series transaction timestamps of the parallel original business data stream, performs cross-system transaction business association matching, and obtains P business process states of P related business chains.

[0018] Parallel time-series material coding features refer to unique codes that identify commodities, futures contracts, or other related materials. Material codes are used in hedging transactions to identify the underlying material of the transaction, such as commodities or contracts. Parallel time-series transaction timestamps are timestamps used to identify the time when a transaction occurs. Each business document, futures transaction record, or settlement data will have a corresponding timestamp, indicating the time when the data was generated or the transaction was completed.

[0019] Since the data comes from multiple systems, a unified parallel time-series material coding feature and parallel time-series transaction timestamp are used to link the data from different systems. For example, transaction records in a futures trading system are linked to accounting or settlement data in a financial system. The parallel time-series material coding feature is used as the matching basis to determine whether the same commodity or contract has been traded in different systems, and the timing and progress of the transactions are further confirmed based on the parallel time-series transaction timestamp. After the association and matching, P related business chains are obtained, where P is a positive integer. The related business chains reflect the progress of related businesses in different systems, and the P business process states are the current state of each related business chain, involving whether a transaction has been completed, whether the settlement has been successful, and whether the financial data has been updated, etc.

[0020] Based on the status of the P business processes, the P related business chains are matched and sent to the P smart finance system nodes for dynamic closed-loop updates of financial data.

[0021] P intelligent financial system nodes are part of a distributed financial system, responsible for processing financial data updates. For example, some nodes specialize in processing hedging accounting entries, while others are responsible for auditing settlement data. These P intelligent financial system nodes receive data from P related business chains, performing dynamic closed-loop updates of financial data. That is, the intelligent financial system nodes update financial data based on the latest status of the related business chains, ensuring that the data in the financial system matches the actual business progress. For example, if the settlement data for a futures contract is available, the financial system will update the corresponding profit and loss calculation results. This ensures the real-time updating and accuracy of financial data, reflecting the latest progress of each business chain.

[0022] After acquiring multi-source incremental changes captured by CDC by listening to the asynchronous message queue, the multi-source incremental changes are loaded into the intermediate data layer based on the asynchronous message queue for business process anomaly identification, and business process update information is output.

[0023] By listening to the asynchronous message queue, multi-source incremental changes captured by CDC (Change Data Capture) can be obtained in real time. CDC is a data capture technology used to monitor data changes in the source system database in real time. Multi-source incremental changes refer to data changes from multiple source systems. Data changes include operations such as adding, modifying or deleting data. Each source system has different data changes. Multi-source incremental changes are captured by CDC to ensure that the latest incremental changes of each source system are obtained in real time.

[0024] Asynchronous message queues are used to transmit messages between different systems, ensuring asynchronous message delivery and processing. Through asynchronous message queues, decoupling between systems can be achieved, ensuring concurrency and efficiency in processing. After incremental data is captured, related changes are transmitted to the intermediate data layer for processing via asynchronous message queues. Asynchronous message queues can effectively handle high-concurrency incremental data, avoiding performance bottlenecks when processing large amounts of data. The intermediate data layer receives and stores multi-source incremental changes and performs business process anomaly identification. This step analyzes multi-source incremental data to identify data anomalies related to the current business process, such as data inconsistency, process interruption, and data conflicts. Based on the anomaly identification results, business process update information is output, indicating which business processes or data are abnormal.

[0025] The business process update information is used to trigger a business status synchronization instruction to roll back the financial data in case of anomalies, and the hedging business status of the P smart financial system nodes is synchronized based on the rollback verification result.

[0026] Based on identified anomalies, a business status synchronization instruction is generated and triggered. This instruction guides how to roll back or resynchronize data, ensuring consistency between business status and financial data within the system. The financial data is rolled back according to the business status synchronization instruction. This operation restores the abnormal financial data to its previous normal state, ensuring the accuracy of financial records. The rollback is based on a previously verified snapshot, historical data, or operation logs. After the financial data rollback, a rollback verification is performed to check if the rolled-back data meets expectations, ensuring that the financial data is restored to a consistent and accurate state. If the rollback verification is successful, it indicates that the financial data has been restored correctly and meets expectations. At this point, P smart finance system nodes are updated according to the rolled-back state to ensure that the status of all relevant financial systems is synchronized.

[0027] Furthermore, cross-system transaction business correlation matching is performed to obtain P business process states of P related business chains. This step includes:

[0028] Constrained by material coding consistency, cross-system transaction business association matching of the parallel time-series material coding characteristics is performed based on multiple business types to obtain the P associated business chains; the parallel time-series transaction timestamps are decomposed using the P associated business chains to obtain P business progress timestamp sequences; business process is determined based on the source of the end timestamp data of the P business progress timestamp sequences, and the status of the P business processes is output.

[0029] Different source systems typically use different coding methods to identify materials. Material coding consistency requires ensuring consistency between material codes across systems, meaning that the codes representing the same material must match in different source systems. This consistency is the foundation for cross-system related transaction data. Different source systems record different types of business data. For example, a product delivery system processes delivery instructions, a futures trading system processes transaction records, and a financial system processes settlement data. Diverse business types refer to the variety of business types within these systems. Therefore, when performing related matching of transaction data, the differences between these business types must be considered. In this step, data matching is performed based on material coding consistency and diverse business types. Through this matching, relevant transaction records for the same material are found from each source system and linked together to form P related business chains.

[0030] Each associated business chain contains a series of transaction events, and each transaction event has a timestamp. These timestamps are used to identify when each transaction event occurs. For example, an associated business chain contains multiple time sequences such as delivery time, transaction time, and settlement time. The parallel time sequence transaction timestamps are decomposed according to the multiple timestamps in each associated business chain to obtain the corresponding business progress timestamp sequence. The end timestamp of the business progress timestamp sequence reflects the final progress of the current business chain.

[0031] The process status of each associated business chain is determined based on the source of the end timestamp data of the P business progress timestamp sequences. Specifically, when the end timestamp comes from the product delivery system, the business process status is determined to be pending execution; when the end timestamp comes from the futures trading system, combined with the condition that the deviation between trading volume and order volume is ≤5%, the business process status is determined to be associated; when the end timestamp comes from the financial system, combined with the condition that the futures and spot profit and loss ratio is ∈ [0.8, 1.25], the business process status is determined to be settled; when the end timestamp is missing or the futures and spot price deviation is >5%, the business process status is determined to require manual intervention.

[0032] Furthermore, based on the status of the P business processes, the P related business chains are matched and sent to the P smart finance system nodes for dynamic closed-loop updates of financial data. This step includes:

[0033] The system interactively obtains multiple sample financial system nodes bound to various sample business processes, and constructs dynamic data encapsulation rules based on these sample business processes and financial system nodes. It then drives these rules to encapsulate the P business process states and P related business chains into P standardized financial data packets, each containing P target node codes. Based on these target node codes, the system sends the P standardized financial data packets to the P intelligent financial system nodes for dynamic closed-loop updates of financial data.

[0034] Multiple sample business processes refer to transaction activities or tasks from various source systems, while multiple sample financial system nodes refer to specific nodes of the financial management system associated with these sample business processes. Each node can be a financial module, accounting account, payment system, etc. Through interactive methods, multiple sample business processes and their associated sample financial system nodes are obtained. This sample data provides the foundation for subsequently constructing dynamic data encapsulation rules. The goal of dynamic data encapsulation rules is to encapsulate different business process states and associated business chains into standardized data packets according to certain rules, so that they can be transmitted to different financial system nodes for processing.

[0035] The data is dynamically encapsulated using data dynamic encapsulation rules. For each business process state and associated business chain, they are encapsulated into standardized financial data packets according to predetermined rules. If a business process is in the "pending execution" state, the encapsulated standardized financial data packet includes business instructions, executed futures contract information, etc. Each standardized financial data packet corresponds to a business process state and an associated business chain. Each standardized financial data packet contains multiple fields, such as material code, transaction timestamp, settlement amount, etc., which are customized according to different business process states and associated business chains. Each standardized financial data packet also includes a target node code, i.e., the identifier of the financial system node, used to identify which financial system node the standardized financial data packet needs to be sent to for processing.

[0036] The target node code corresponds to a specific intelligent finance system node. Based on the target node code, standardized financial data packets are sent to the corresponding intelligent finance system node. For example, one intelligent finance system node might be specifically responsible for processing futures settlement data, while another node manages product delivery-related financial data. After sending the standardized financial data packets to the corresponding intelligent finance system node, the node dynamically updates its financial data in a closed loop based on the received data. That is, it updates its accounts, transaction records, or settlement status in real time based on newly received financial data. For example, if it receives futures transaction settlement data, the intelligent finance system node needs to update the futures transaction profit and loss data, the balance of the financial account, etc. This process includes data verification, settlement verification, payment confirmation, and other steps to ensure that all financial records are accurate and consistent with the actual business progress.

[0037] Furthermore, after acquiring multi-source incremental changes captured by CDC by listening to the asynchronous message queue, the multi-source incremental changes are loaded into the intermediate data layer based on the asynchronous message queue for business process anomaly identification, and business process update information is output. This step includes:

[0038] The multi-source incremental changes are rearranged based on incremental change priority to obtain a change priority sequence. During the process of dynamically loading the change priority sequence to the intermediate data layer based on an asynchronous message queue, state conflict detection is performed between the multi-source incremental changes and P business process states, and the business process update information is output. The business process update information includes M business update states, M≤P, where M is a positive integer. The M business process states and the M business update states are compared to obtain M state rollback instructions. The M state rollback instructions are bound to the M business update states.

[0039] Incremental changes refer to updates or changes that occur in the source system during data storage and updating. These changes are usually carried out gradually rather than as a one-time large-scale change. They mainly include updating data fields, adding or deleting records, etc. The priority of incremental changes is determined based on business logic and system requirements. For example, data correction takes precedence over other changes, newer changes have higher priority, changes involving multiple systems or key business processes have higher priority, and some changes can only be executed after other operations are completed. Reordering multi-source incremental changes based on incremental change priority means re-sorting the multi-source incremental changes according to their importance and processing order. The reordered sequence represents the processing order of each incremental change.

[0040] Asynchronous message queues are used to transmit messages between different systems. Incremental changes are loaded into the intermediate data layer according to the change priority sequence. During this process, state conflict detection is performed. State conflict refers to the inconsistency or conflict between incremental changes from different source systems and the current P business process states. For example, if a business process has been marked as "settled", but a new incremental change involves the trading volume or settlement amount of futures trading, this means a data conflict. The detected conflicting incremental changes are marked and recorded as business process update information output. The business process update information includes M business update states, where M is the number of business process states that need to be rolled back or adjusted, M≤P, because conflicting states only affect a portion of the ongoing business processes, not all business processes.

[0041] The system compares the states of M business processes with the states of M business updates. The goal of the comparison is to determine which business processes need to be rolled back and which need to continue execution. After the comparison is completed, it identifies which state updates are inconsistent or incorrect and generates corresponding M state rollback instructions. The state rollback instructions indicate that inappropriate changes should be undone and the process should be restored to the previous stable state. For example, if an incremental change causes an error in the profit and loss calculation of futures trading, a corresponding state rollback instruction is generated to undone the change and restore the business process state to the correct state.

[0042] The generated M state rollback instructions are bound to the corresponding M business update states. This means that each state rollback instruction is associated with the corresponding business update state to ensure that the rollback operation can be executed accurately. When the rollback is actually executed, the state of the business process is accurately restored based on these state rollback instructions to avoid data loss or errors.

[0043] Furthermore, the business process update information is used to trigger a business status synchronization instruction to roll back financial data in case of anomalies, and the hedging business status of the P smart financial system nodes is synchronized based on the rollback verification result. This step includes:

[0044] Based on the M state rollback instructions, locate the M update node codes; based on the M target node codes of the M business process states, send the M state rollback instructions to the M smart financial system nodes for financial data anomaly rollback verification; if the verification passes, send the M business update states to the M updated financial system nodes based on the M update node codes; if the verification fails, trigger state rollback to pending execution.

[0045] The corresponding update node code is determined based on the status rollback instruction. These update node codes identify the specific financial system node that needs to be rolled back. For example, if a status rollback instruction involves an error in the profit and loss calculation in the futures trading system, then it is necessary to locate the update node code of the futures trading system and perform the corresponding rollback operation.

[0046] Based on the identified M target node codes, corresponding M status rollback instructions are sent to the corresponding M intelligent financial system nodes. These intelligent financial system nodes are system modules related to hedging operations, specifically handling hedging-related financial data and business logic. These nodes possess strong intelligence and automation capabilities, enabling them to automatically handle rollback operations according to business rules. Upon receiving a status rollback instruction, each intelligent financial system node performs a financial data anomaly rollback verification. The purpose is to confirm whether the current data conforms to business rules and ensure that the rolled-back data will not cause other financial anomalies. Rollback verification includes checking the completeness and accuracy of the rolled-back data, comparing the rolled-back data with the system's historical status, and confirming whether the rollback conforms to predetermined financial rules, such as profit and loss calculation rules and fund settlement rules.

[0047] If the rollback verification passes, processing continues. At this point, based on the previously located M update node codes, the M business update statuses are sent to the corresponding M update financial system nodes. Each update financial system node makes corresponding adjustments based on the received business update status. For example, the product delivery system updates the product delivery status or related financial records, the futures trading system recalculates profit and loss data and updates the corresponding transaction records, and the financial settlement system recalculates settlement data and ensures that the profit and loss of futures trading is consistent with the settlement data.

[0048] If the rollback verification fails, it means that the rolled-back data is abnormal, cannot meet the expected financial rules, or has data inconsistency. In this case, the status is triggered to rollback to pending execution, that is, the business process is marked as pending processing or pending review. This means that the execution of the business needs to be suspended or delayed until the administrator or automated process further checks and confirms whether the rollback operation can continue.

[0049] Furthermore, the parallel hedging core data system includes a parallel product delivery system, a futures trading system, and a financial system, and the parallel raw business data stream includes timestamp-aligned basic hedging business documents, futures transaction records, and settlement data.

[0050] The product delivery system manages and tracks delivered products and related information, such as commodity, quantity, delivery time, and delivery location; the futures trading system is responsible for transaction records in the futures market, including buying and selling operations of futures contracts, transaction prices, and transaction times; the financial system records and manages financial data, involving various cash flows, costs, profits, and accounting entries. The parallel operation of these systems means they operate independently but are interconnected. In hedging operations, it is necessary to ensure that their data is updated and matched synchronously, forming a coherent business chain.

[0051] The basic hedging transaction documents are the core documents for hedging operations, containing fundamental information such as the traded commodity, quantity, and price. Futures transaction records refer to specific futures trading data within the futures trading system, including transaction price, quantity, and time. Settlement data includes the settlement price, margin changes, and profit / loss after the futures transaction, reflecting the financial results of the hedging process. Timestamp alignment means that these data from different sources have timestamp information. Synchronizing these data using timestamps ensures correct data matching across different systems.

[0052] Furthermore, the intermediate data layer receives and extracts the parallel time-series material coding features and parallel time-series transaction timestamps of the parallel raw business data stream, prior to which includes:

[0053] After hashing and deduplicating the basic hedging business documents based on the unique document identifier, daily splitting is performed to obtain hedging correction business documents. The contract code field of the futures transaction records is checked for completeness. Missing contract code sequences are obtained, and these sequences are completed based on the transaction timestamp to obtain corrected transaction records. Invalid fields are cleared from the corrected transaction records based on the hedging instruction association key to obtain valid transaction records. The hedging instruction association key consists of the contract code and transaction timestamp of the futures transaction record. The parallel original business data stream is mapped and replaced using the hedging correction business documents and valid transaction records to output a parallel corrected business data stream. The parallel time-series material coding features and parallel time-series transaction timestamps are extracted from the parallel corrected business data stream.

[0054] A unique document identifier is determined for each hedging basic business document, such as a document number or transaction number. These unique document identifiers are used to identify and distinguish different hedging basic business documents. Hash deduplication refers to using a hash algorithm to encrypt the unique document identifier of the hedging basic business document, generating a hash value. If duplicate hedging basic business documents exist in the data (possibly due to system synchronization or data entry errors), hash deduplication can quickly identify and remove duplicate hedging basic business documents, ensuring the uniqueness and accuracy of each hedging basic business document in the system.

[0055] After hash deduplication, each valid hedging basic business document is split daily, which means splitting and organizing the document according to time (usually by day). For example, if there are multiple hedging operations on a certain day, these operations are split into separate records. After hash deduplication and daily splitting, a hedging correction business document is generated, which contains the split, deduplicated, and corrected hedging-related data, ready to enter the next processing step.

[0056] The contract code field is a code that identifies the futures product and contract, such as "al2509". It is used to identify a specific futures contract. Integrity verification means checking whether there are any missing or incomplete contract code fields in each futures transaction record. After the verification process, all records with missing contract codes are identified. These records may have been omitted or entered incorrectly during transaction entry, resulting in missing contract code fields. The missing contract code sequence is these records with missing contract codes. They need to be repaired or supplemented to ensure the integrity and consistency of futures transaction records.

[0057] For missing contract code sequences, they are completed using transaction timestamps. A transaction timestamp is a time marker that indicates the specific time of a futures transaction. For example, the trading time range of a certain futures contract is known, such as the start and end date of a certain year. The transaction time is used to determine which contract the transaction record belongs to. The completion method includes inferring the missing contract code based on the timestamp and finding the valid contract corresponding to the timestamp from historical data. After the contract code is completed, the corrected transaction record is obtained, ensuring that each futures transaction record contains complete information.

[0058] The hedging instruction association key is composed of the contract code and the transaction timestamp in the futures transaction record. The contract code represents the specific type of futures contract, and the transaction timestamp marks the specific time of the transaction. The function of the hedging instruction association key is to accurately match the futures transaction record with other hedging-related data (such as hedging instructions, product delivery, settlement records, etc.). In other words, this hedging instruction association key is the key basis for cross-system business matching and data association.

[0059] In futures transaction records, there are some invalid fields. These invalid fields may be due to system input errors, data loss, or fields that do not comply with business rules. For example, field values ​​may be empty, invalid, or formatted incorrectly. By using the hedging instruction association key, namely the contract code and the transaction timestamp, each futures transaction record is located, and invalid fields are cleared to obtain valid transaction records. Valid transaction records contain accurate, complete data that complies with business rules.

[0060] The mapping and replacement process involves matching and replacing the corrected warranty correction business documents and valid transaction records with the corresponding records in the parallel original business data stream. The purpose is to update or correct erroneous information in the original data stream, ensuring the accuracy and consistency of the data stream. Through mapping and replacement, a parallel corrected business data stream is ultimately generated.

[0061] Material codes are unique codes used to identify different products or varieties, such as the ID of a commodity or futures contract. Extracting parallel time-series material code features from the parallel corrected business data stream can be understood as a set of material codes with time-series attributes, reflecting the various products or futures varieties involved at different points in time. In different business data streams, each transaction or business event has a timestamp, marking the specific time it occurred. These timestamps are extracted from the parallel corrected business data stream and used to form a unified parallel time-series transaction timestamp based on the different business data streams, used to synchronize transaction events between different systems.

[0062] Furthermore, the step of extracting the parallel time-series material coding features and parallel time-series transaction timestamps from the parallel correction business data stream includes:

[0063] After extracting the original material code sequence from the hedging and rectification business documents, the original material code sequence is transformed based on the commodity material mapping table to obtain a standard futures commodity code sequence as the first time-series material code feature; the document creation time field is extracted from the hedging and rectification business documents to obtain the first time-series transaction timestamp; after extracting the contract code sequence from the valid transaction records, the commodity code sequence is reverse-analyzed based on the contract code sequence to obtain the second time-series material code feature; millisecond-level transaction timestamps are extracted from the valid transaction records to output the second time-series transaction timestamp; the settlement voucher generation timestamp is extracted from the settlement data to obtain the third time-series transaction timestamp; the first time-series transaction timestamp, the second time-series transaction timestamp, and the third time-series transaction timestamp constitute the parallel time-series transaction timestamp; the first time-series material code feature and the second time-series material code feature constitute the parallel time-series material code feature.

[0064] The original material code sequence is extracted from the hedging correction business document. The original material code sequence identifies the specific material involved in the hedging process. The commodity material mapping table contains the mapping relationship between material codes and futures commodity codes. The extracted original material code sequence is converted into a standard futures commodity code sequence using the commodity material mapping table. The futures commodity code is a standard code used to distinguish different products in the futures market. Using the standard futures commodity code sequence as the first time-series material coding feature provides a unified standard for subsequent data matching and processing, helps to eliminate possible coding differences, and ensures that subsequent operations can be carried out based on consistent data.

[0065] The document creation time field is extracted from the warranty service documents. This field records the specific time when each document was created, representing the initiation time of the transaction. The extracted document creation time field serves as the first time-series transaction timestamp. By accurately obtaining the document creation time, the timeliness and orderliness of data processing can be guaranteed, avoiding errors caused by time deviations or inconsistencies.

[0066] Contract code sequences are extracted from valid transaction records. Each contract code identifies a specific futures product. Using predefined mapping relationships, such as the mapping between contract codes and futures varieties, the variety code corresponding to each contract code is obtained through reverse parsing. The variety code represents the commodity variety corresponding to a specific futures contract. The variety code sequence obtained from reverse parsing is used as the second time-series commodity code feature, ensuring the consistency and accuracy of commodity codes in futures trading.

[0067] The system extracts transaction timestamps from valid futures transaction records, ensuring the timestamps are accurate to the millisecond level. Existing timestamps typically only have second-level accuracy, while millisecond-level timestamps provide finer-grained time data for handling high-speed or high-frequency trading analysis. These extracted millisecond-level transaction timestamps serve as secondary time-series transaction timestamps, playing a crucial role in subsequent time-series analysis and data synchronization, especially when processing high-frequency trading data.

[0068] The settlement voucher generation timestamp is extracted from the settlement data. The settlement voucher marks the completion of the settlement process, and the settlement voucher generation timestamp marks the time information of the entire process from futures transaction to settlement. The extracted settlement voucher generation timestamp serves as the third time-series transaction timestamp. By introducing the settlement voucher generation timestamp, the settlement process of the transaction can be accurately tracked and controlled, providing an accurate time basis for subsequent financial system data synchronization.

[0069] The first, second, and third time-series transaction timestamps are arranged in chronological order to form a parallel time-series transaction timestamp. This time sequence is a fusion of time information from multiple business processes, which can better reflect the time progress of the entire transaction process.

[0070] The first time-series material coding features and the second time-series material coding features are integrated to form a complete parallel time-series material coding feature, so as to achieve more accurate cross-system material matching.

[0071] Furthermore, the method also includes:

[0072] Using the second time-series transaction timestamp as a benchmark, the first time-series transaction timestamp is calibrated using a sliding window. If the deviation between the first and second time-series transaction timestamps exceeds 5% within W consecutive time windows, a business data anomaly alarm is triggered. If the deviation between the first and second time-series transaction timestamps does not exceed 5% within W consecutive time windows, the calibrated first, second, and third time-series transaction timestamps are bound together to obtain the parallel time-series transaction timestamps. The first and second time-series material coding features are bound together as a material coding feature tuple, which is output as the parallel time-series material coding feature.

[0073] Using the second time-series transaction timestamp (millisecond-level transaction timestamp) as a reference standard, the first time-series transaction timestamp (document creation time field) is calibrated. Through the sliding window technique, this calibration process is carried out within a series of continuous time windows, that is, the first time-series transaction timestamp is corrected in multiple time periods. The sliding window can ensure that the calibration is not just a single time adjustment, but is dynamic and continuous. This allows for flexible adjustment of timestamps in the data stream, reducing errors caused by local anomalies.

[0074] The first and second time-series transaction timestamps are compared. If their deviation exceeds 5% within P consecutive time windows, it indicates a significant error in the time synchronization between the two systems. A deviation exceeding 5% means the deviation exceeds the tolerance range. P is a positive integer, set according to specific requirements. The deviation is calculated as the ratio of the time difference to the expected value. When the threshold is exceeded, it is considered an anomaly. In this case, a business data anomaly alarm is automatically triggered, and relevant personnel are notified to check and handle the issue through a message queue or alarm system.

[0075] The first and second time-series transaction timestamps are compared. If their deviation within P consecutive time windows does not exceed 5%, their time synchronization accuracy is considered sufficiently high, and subsequent operations continue. In this case, the calibrated first and second time-series transaction timestamps are bound to a third time-series transaction timestamp from settlement data, forming a parallel time-series transaction timestamp containing three system timestamps. This parallel time-series transaction timestamp serves as a standardized timeline for the entire business process, ensuring that data from different systems is time-aligned.

[0076] The first-time-series material coding features and the second-time-series material coding features are bound together to form material coding feature tuples. These tuples represent different representations of the same material in different systems. This binding ensures that different codes for the same material can be associated across multiple systems. The material coding feature tuples are then output as parallel time-series material coding features for subsequent data mapping and processing.

[0077] Example 2, based on the same inventive concept as the adaptive correlation and interactive synchronization method for hedging business data in the foregoing examples, such as... Figure 2 As shown in the figure, this application provides an adaptive correlation and interactive synchronization system for hedging business data. The adaptive correlation and interactive synchronization system for hedging business data includes:

[0078] The data stream loading module 10 is used to load the parallel raw business data stream of the parallel hedging core data system into the intermediate data layer after the parallel API interface captures the parallel raw business data stream based on the near real-time synchronization mechanism. The business association matching module 20 is used by the intermediate data layer to receive and extract the parallel time-series material coding features and parallel time-series transaction timestamps of the parallel raw business data stream, perform cross-system transaction business association matching, and obtain the P business process states of P related business chains. The closed-loop update module 30 is used to send the P related business chains to P smart financial system nodes for dynamic closed-loop update of financial data according to the P business process states. The anomaly identification module 40 is used to obtain the multi-source incremental changes captured by CDC by listening to the asynchronous message queue, load the multi-source incremental changes to the intermediate data layer based on the asynchronous message queue for business process anomaly identification, and output business process update information. The status synchronization module 50 is used to trigger the business status synchronization instruction to roll back the financial data anomaly using the business process update information, and synchronize the hedging business status of the P smart financial system nodes according to the rollback verification result.

[0079] Furthermore, the business association matching module 20 is used to perform the following operation steps:

[0080] Constrained by material coding consistency, cross-system transaction business association matching of the parallel time-series material coding characteristics is performed based on multiple business types to obtain the P associated business chains; the parallel time-series transaction timestamps are decomposed using the P associated business chains to obtain P business progress timestamp sequences; business process is determined based on the source of the end timestamp data of the P business progress timestamp sequences, and the status of the P business processes is output.

[0081] Furthermore, the closed-loop update module 30 is used to perform the following operation steps:

[0082] The system interactively obtains multiple sample financial system nodes bound to various sample business processes, and constructs dynamic data encapsulation rules based on these sample business processes and financial system nodes. It then drives these rules to encapsulate the P business process states and P related business chains into P standardized financial data packets, each containing P target node codes. Based on these target node codes, the system sends the P standardized financial data packets to the P intelligent financial system nodes for dynamic closed-loop updates of financial data.

[0083] Furthermore, the anomaly detection module 40 is used to perform the following operation steps:

[0084] The multi-source incremental changes are rearranged based on incremental change priority to obtain a change priority sequence. During the process of dynamically loading the change priority sequence to the intermediate data layer based on an asynchronous message queue, state conflict detection is performed between the multi-source incremental changes and P business process states, and the business process update information is output. The business process update information includes M business update states, M≤P, where M is a positive integer. The M business process states and the M business update states are compared to obtain M state rollback instructions. The M state rollback instructions are bound to the M business update states.

[0085] Furthermore, the state synchronization module 50 is used to perform the following operation steps:

[0086] Based on the M state rollback instructions, locate the M update node codes; based on the M target node codes of the M business process states, send the M state rollback instructions to the M smart financial system nodes for financial data anomaly rollback verification; if the verification passes, send the M business update states to the M updated financial system nodes based on the M update node codes; if the verification fails, trigger state rollback to pending execution.

[0087] Furthermore, the parallel hedging core data system includes a parallel product delivery system, a futures trading system, and a financial system, and the parallel raw business data stream includes timestamp-aligned basic hedging business documents, futures transaction records, and settlement data.

[0088] Furthermore, the business association matching module 20 is used to perform the following operation steps:

[0089] After hashing and deduplicating the basic hedging business documents based on the unique document identifier, daily splitting is performed to obtain hedging correction business documents. The contract code field of the futures transaction records is checked for completeness. Missing contract code sequences are obtained, and these sequences are completed based on the transaction timestamp to obtain corrected transaction records. Invalid fields are cleared from the corrected transaction records based on the hedging instruction association key to obtain valid transaction records. The hedging instruction association key consists of the contract code and transaction timestamp of the futures transaction record. The parallel original business data stream is mapped and replaced using the hedging correction business documents and valid transaction records to output a parallel corrected business data stream. The parallel time-series material coding features and parallel time-series transaction timestamps are extracted from the parallel corrected business data stream.

[0090] Furthermore, the business association matching module 20 is used to perform the following operation steps:

[0091] After extracting the original material code sequence from the hedging and rectification business documents, the original material code sequence is transformed based on the commodity material mapping table to obtain a standard futures commodity code sequence as the first time-series material code feature; the document creation time field is extracted from the hedging and rectification business documents to obtain the first time-series transaction timestamp; after extracting the contract code sequence from the valid transaction records, the commodity code sequence is reverse-analyzed based on the contract code sequence to obtain the second time-series material code feature; millisecond-level transaction timestamps are extracted from the valid transaction records to output the second time-series transaction timestamp; the settlement voucher generation timestamp is extracted from the settlement data to obtain the third time-series transaction timestamp; the first time-series transaction timestamp, the second time-series transaction timestamp, and the third time-series transaction timestamp constitute the parallel time-series transaction timestamp; the first time-series material code feature and the second time-series material code feature constitute the parallel time-series material code feature.

[0092] Furthermore, the business association matching module 20 is used to perform the following operation steps:

[0093] Using the second time-series transaction timestamp as a benchmark, the first time-series transaction timestamp is calibrated using a sliding window. If the deviation between the first and second time-series transaction timestamps exceeds 5% within W consecutive time windows, a business data anomaly alarm is triggered. If the deviation between the first and second time-series transaction timestamps does not exceed 5% within W consecutive time windows, the calibrated first, second, and third time-series transaction timestamps are bound together to obtain the parallel time-series transaction timestamps. The first and second time-series material coding features are bound together as a material coding feature tuple, which is output as the parallel time-series material coding feature.

[0094] Through the foregoing detailed description of the adaptive correlation and interactive synchronization method for hedging business data, those skilled in the art can clearly understand the adaptive correlation and interactive synchronization system for hedging business data in this embodiment. Since it corresponds to the method disclosed in the embodiment, the description is relatively simple, and relevant parts can be referred to the method section.

[0095] The above description of the disclosed embodiments enables those skilled in the art to make or use this application. Various modifications to these embodiments will be readily apparent to those skilled in the art, and the general principles defined herein may be implemented in other embodiments without departing from the spirit or scope of this application. Therefore, this application is not to be limited to the embodiments shown herein, but is to be accorded the widest scope consistent with the principles and novel features disclosed herein.

Claims

1. An adaptive correlation and interactive synchronization method for hedging business data, characterized in that, The method includes: After the parallel API interface captures the parallel raw business data stream of the parallel hedging core data system based on a near real-time synchronization mechanism, it loads the parallel raw business data stream into the intermediate data layer. The intermediate data layer receives and extracts the parallel time-series material coding features and parallel time-series transaction timestamps of the parallel original business data stream, performs cross-system transaction business association matching, and obtains P business process states of P related business chains. Based on the status of the P business processes, the P related business chains are matched and sent to the P smart finance system nodes for dynamic closed-loop updates of financial data. After obtaining the multi-source incremental changes captured by CDC by listening to the asynchronous message queue, the multi-source incremental changes are loaded into the intermediate data layer based on the asynchronous message queue to identify business process anomalies and output business process update information. The process includes, among other things, acquiring multi-source incremental changes captured by CDC through listening to an asynchronous message queue, loading these multi-source incremental changes to the intermediate data layer based on the asynchronous message queue for business process anomaly identification, and outputting business process update information. The multi-source incremental changes are rearranged based on the incremental change priority to obtain a change priority sequence; During the process of dynamically loading the change priority sequence to the intermediate data layer based on the asynchronous message queue, the state conflict detection between the multi-source incremental change and the state of P business processes is performed, and the business process update information is output. The business process update information includes M business update states, M≤P, and M is a positive integer. By comparing the states of M service processes with the update states of the M services, M state rollback instructions are obtained. Bind the M state rollback instructions to the M service update states; The business process update information is used to trigger a business status synchronization instruction to roll back the financial data in case of anomalies, and the hedging business status of the P smart financial system nodes is synchronized based on the rollback verification result. The process of triggering a business status synchronization instruction using the business process update information to roll back financial data in case of anomalies, and synchronizing the hedging business status of the P smart financial system nodes based on the rollback verification results, includes the following steps: Based on the M state rollback instructions, locate the M update node codes; Based on the M target node codes of the M business process states, the M state rollback instructions are sent to the M smart financial system nodes for financial data anomaly rollback verification. If the verification passes, the M business update statuses are sent to the M financial system update nodes according to the M update node codes; If the verification fails, the status will be rolled back to pending execution.

2. The adaptive correlation and interactive synchronization method for hedging business data as described in claim 1, characterized in that, Perform cross-system transaction business association matching to obtain P business process states of P related business chains. This step includes: With material coding consistency as a constraint, cross-system transaction business association matching is performed based on multiple business types to obtain the P associated business chains; The parallel time-series transaction timestamps are decomposed using the P associated business chains to obtain P business progress timestamp sequences; The business process is determined based on the source of the last timestamp data of the P business progress timestamp sequences, and the status of the P business processes is output.

3. The adaptive correlation and interactive synchronization method for hedging business data as described in claim 1, characterized in that, Based on the status of the P business processes, the P related business chains are matched and sent to the P smart finance system nodes for dynamic closed-loop updates of financial data. This step includes: The system interactively obtains multiple sample financial system nodes bound to various sample business processes, and constructs dynamic data encapsulation rules based on the various sample business processes and multiple sample financial system nodes. The data dynamic encapsulation rule drives the encapsulation of the P business process states and P related business chains into P standardized financial data packets, wherein the P standardized financial data packets carry P target node codes; Based on the P target node codes, the P standardized financial data packets are sent to the P intelligent financial system nodes for dynamic closed-loop updates of financial data.

4. The adaptive correlation and interactive synchronization method for hedging business data as described in claim 1, characterized in that, The parallel hedging core data system includes a parallel product delivery system, a futures trading system, and a financial system. The parallel raw business data stream includes timestamp-aligned basic hedging business documents, futures transaction records, and settlement data.

5. The adaptive correlation and interactive synchronization method for hedging business data as described in claim 4, characterized in that, The intermediate data layer receives and extracts the parallel time-series material coding features and parallel time-series transaction timestamps of the parallel raw business data stream, prior to which includes: After hashing and deduplicating the basic hedging business documents based on the unique document identifier, the documents are split daily to obtain the hedging correction business documents. The contract code field of the futures transaction record is checked for completeness. After obtaining the missing contract code sequence, the missing contract code sequence is completed based on the transaction timestamp to obtain the corrected transaction record. The corrected transaction records are traversed based on the hedging instruction association key to remove invalid fields and obtain valid transaction records. The hedging instruction association key consists of the contract code and transaction timestamp of the futures transaction record. The parallel original business data stream is mapped and replaced using the warranty correction business documents and valid transaction records, and a parallel corrected business data stream is output. Extract the parallel time-series material coding features and parallel time-series transaction timestamps from the parallel correction business data stream.

6. The adaptive correlation and interactive synchronization method for hedging business data as described in claim 5, characterized in that, The step of extracting the parallel time-series material coding features and parallel time-series transaction timestamps from the parallel correction business data stream includes: After extracting the original material code sequence from the warranty and repair business document, the original material code sequence is transformed based on the commodity material mapping table to obtain the standard futures commodity code sequence as the first time-series material code feature; Iterate through the warranty and authenticity business documents and extract the document creation time field to obtain the first time-series transaction timestamp; After traversing the valid transaction records to extract the contract code sequence, the commodity code sequence is reverse-analyzed based on the contract code sequence as the second time-series material coding feature; Extract millisecond-level transaction timestamps from the valid transaction records and output the second time-series transaction timestamps; The settlement data is traversed to extract the settlement voucher generation timestamp, thus obtaining the third time-series transaction timestamp; The first time-series transaction timestamp, the second time-series transaction timestamp, and the third time-series transaction timestamp constitute the parallel time-series transaction timestamp; The first time-series material coding feature and the second time-series material coding feature constitute the parallel time-series material coding feature.

7. The adaptive correlation and interactive synchronization method for hedging business data as described in claim 6, characterized in that, The method further includes: Using the second time-series transaction timestamp as a benchmark, the first time-series transaction timestamp is calibrated using a sliding window. If the first time-series transaction timestamp and the second time-series transaction timestamp deviate by more than 5% within W consecutive time windows, a business data anomaly alarm will be triggered. If the deviation between the first time-series transaction timestamp and the second time-series transaction timestamp does not exceed 5% within W consecutive time windows, then the first time-series transaction timestamp, the second time-series transaction timestamp, and the third time-series transaction timestamp are bound together to obtain the parallel time-series transaction timestamp. The first time-series material coding feature and the second time-series material coding feature are bound together as a material coding feature tuple, which is then output as the parallel time-series material coding feature.

8. An adaptive correlation and interactive synchronization system for hedging business data, characterized in that, For implementing the adaptive correlation and interactive synchronization method for hedging business data according to any one of claims 1-7, the adaptive correlation and interactive synchronization system for hedging business data comprises: The data stream loading module is used to load the parallel raw business data stream of the parallel hedging core data system into the intermediate data layer after the parallel API interface captures the parallel raw business data stream based on the near real-time synchronization mechanism. The business association matching module is used by the intermediate data layer to receive and extract the parallel time-series material coding features and parallel time-series transaction timestamps of the parallel original business data stream, perform cross-system transaction business association matching, and obtain P business process states of P associated business chains. The closed-loop update module is used to match and send the P related business chains to the P smart financial system nodes according to the status of the P business processes to perform dynamic closed-loop updates of financial data. The anomaly identification module is used to obtain multi-source incremental changes captured by CDC by listening to the asynchronous message queue, load the multi-source incremental changes to the intermediate data layer based on the asynchronous message queue to identify business process anomalies, and output business process update information. The status synchronization module is used to trigger a business status synchronization instruction using the business process update information to roll back the financial data in case of anomalies, and to synchronize the hedging business status of the P smart financial system nodes based on the rollback verification results.

Images