An OTC derivative lifecycle management system and method

Abstract

The application discloses a kind of off-site derivative life cycle management system and method, specifically related to off-site transaction technical field, specific steps include based on predefined transaction field, construct the uniform transaction identification for uniquely identifying off-site derivative transaction, the transaction confirmation data from different transaction source systems is structured and parsed, construct floating interest rate cash flow prediction model, model output is compared with transaction counterparty confirmation result verification, construct uniform transaction view, realize the cross-system state synchronization and consistency maintenance of transaction life cycle event, calculate the intervention depth index and data structure difference index of business system in current transaction link, generate automated credibility score, for quantifying the reliability level of transaction in current transaction link realizes automatic processing, through reliability verification mechanism, improve the credibility and necessity of manual intervention, prevent data pollution or downstream state disorder caused by error automatic processing.

Description

TECHNICAL FIELD

[0001] The present application relates to the technical field of over-the-counter transactions, and more particularly to an over-the-counter derivative life cycle management system and method. BACKGROUND

[0002] Existing over-the-counter transactions usually use free-form text, emails or telephone to communicate and confirm. Different forms of over-the-counter derivatives result in inconsistent transaction master data, confirmation data and valuation data. There is a lack of a unified transaction master anchor structure to track the status of over-the-counter derivatives in all systems. It is difficult to directly convert the legal existence of over-the-counter derivatives into a digital tag that can be identified and tracked. Over-the-counter derivatives have non-standardized characteristics and rely on manual input of transaction terms. Even if the confirmation text is clear, there is still a possibility that the system cannot accurately extract special fields such as floating interest rate formulas. Manual review is highly dependent on human intervention.

[0003] In the current over-the-counter derivative life cycle management, the interfaces between systems are heterogeneous and the field understanding is greatly different, resulting in automation failure or error that is difficult to perceive. The participation of each system in different stages of the life cycle is greatly different, resulting in that part of the processing relies too much on manual work without mechanism control. There is a lack of an effective pre-judgment mechanism to determine whether manual review is necessary, resulting in an increase in the workload of manual intervention and an increase in the probability of human error, which further affects the stability of over-the-counter derivative life cycle management.

[0004] To solve the above-mentioned defects, a technical solution is proposed. SUMMARY

[0005] The purpose of the present application is to provide an over-the-counter derivative life cycle management system and method to solve the problems in the background art.

[0006] To achieve the above-mentioned purpose, the present application provides the following technical solution: an over-the-counter derivative life cycle management method, the specific steps of which include:

[0007] Based on the predefined transaction fields, a unified transaction identifier for uniquely identifying over-the-counter derivative transactions is constructed, and the unified transaction identifier uniquely identifies the same over-the-counter derivative transaction across systems.

[0008] The transaction confirmation data from different transaction source systems are structurally parsed, transaction fields are identified and extracted, including but not limited to frequency fields, floating interest rate calculation formula fields, and nominal amount fields. Based on the set field semantic mapping rules, each field is converted to a standard format.

[0009] Based on the parsed standardized transaction confirmation data, a floating interest rate cash flow prediction model is constructed, and by comparing the floating interest rate cash flow prediction model output result with the transaction counterparty confirmation result, double verification of the correctness of the floating interest rate formula and the consistency of the valuation is realized, if the verification is inconsistent, a verification process is triggered;

[0010] Based on the unified transaction identifier and the standardized transaction confirmation data, a unified transaction view is constructed, when a certain life cycle event is recorded in any business system, the event is synchronized to other business systems through the unified transaction view interface, realizing cross-system state synchronization and consistency maintenance of transaction life cycle events;

[0011] For each business system participating in comparison, the intervention depth index and the data structure difference index of the system in the current transaction link are calculated, the intervention depth index is used to measure the direct generation or modification ability of the system to the key field, and the data structure difference index is used to evaluate the heterogeneous degree of data format, interface standard and field granularity between systems;

[0012] Based on the intervention depth index, the data structure difference index and the field consistency comparison result, an automatic trustworthiness score is generated, which is used to quantify the reliability level of automatic processing of transactions in the current transaction link;

[0013] If the automatic trustworthiness score is lower than the preset threshold, the transaction is marked as a transaction identifier loss state, and a manual intervention process is triggered to avoid affecting the subsequent life cycle processing process.

[0014] In a preferred embodiment, the fields required to constitute the transaction identifier are extracted from the transaction confirmation data, transaction input data or transaction matching system, the fields at least include but are not limited to one or more of the following: transaction counterparty identifier, transaction effective date, expiration date, product type, nominal amount, transaction currency, quotation direction and quotation method, the above fields are standardized, and a hash function is used to perform digest operation on the standardized field combination, to generate a unified transaction identifier;

[0015] For high similarity but not completely repeated transaction records, a configurable field weighting comparison mechanism is introduced to resolve conflicts of transaction records, ensuring the consistency of the unified transaction identifier;

[0016] The generated unified transaction identifier is written into the main transaction database as the primary key, and a mapping relationship with the original transaction number is established, the unified transaction identifier is synchronized to the downstream modules of the valuation system, the risk control system and the accounting system through the interface, realizing cross-system consistency tracking;

[0017] Based on the anomaly identification handling mechanism, when a key field is missing, the transaction is marked with an "abnormal transaction identification" status and a review and intervention process is triggered to prevent abnormal transaction identification from affecting downstream lifecycle processing.

[0018] In a preferred embodiment, a configurable field-weighted comparison mechanism is introduced. The logic for conflict resolution of highly similar but not completely duplicated transaction records is as follows:

[0019] The business system administrator pre-sets a set of comparison fields, including but not limited to: counterparty, transaction type, transaction start date, transaction end date, notional amount, floating interest rate definition, frequency, currency pair, transaction direction, and contract identifier. Each comparison field is assigned a corresponding weight value to represent the field's influence on the overall similarity judgment. Among them, counterparty, transaction type, floating interest rate definition, frequency, currency pair, transaction direction, and contract identifier are text fields, notional amount is a numeric field, and transaction start date and transaction end date are date fields.

[0020] For the two transactions to be compared, the above field values ​​are extracted for field similarity assessment. Edit distance similarity assessment is used for text fields, dual threshold similarity assessment using absolute difference and relative difference is used for numerical fields, and tolerable range similarity assessment is used for date fields.

[0021] After completing the field similarity assessment, based on the preset field weights... ,in For a set of preset field weights, Let i be the field index and t be the total number of fields in the set, and let t be the weight of each field. Perform weighted aggregation, where... For the set of similarity scores for each field, To calculate the overall transaction similarity based on field similarity, the calculation expression is as follows: In the formula, For overall transaction similarity;

[0022] Set the resolution threshold to Dith, and if the calculated overall transaction similarity... If the overall transaction similarity is greater than or equal to the resolution threshold Dith, then the two transactions to be compared are determined to be the same transaction logic instance, and the transaction record with the latest modification time is automatically saved. If the two transactions are less than the resolution threshold Dith, they are determined to be independent transactions and will not be merged. An anomaly identification mechanism will be used to prevent anomalies from occurring.

[0023] In a preferred embodiment, the method for evaluating text fields using edit distance similarity is as follows:

[0024] For the texts of two transactions to be compared, the minimum number of operations required to make them identical by insertion, deletion or substitution is denoted as Ded, and the similarity of the text fields is calculated according to the maximum length Lmax of the texts, with the expression wherein is the similarity of the text fields, and the maximum length Lmax of the texts is the maximum length of the two texts involved in the comparison, wherein 1 represents that the text fields of the two transactions are identical;

[0025] For the numerical fields, the method of double threshold similarity evaluation of absolute difference and relative difference is as follows:

[0026] The absolute difference of the numerical fields of the two transactions to be compared is calculated, and the absolute difference is wherein is the absolute difference, and are the values of the same numerical field of the two transactions to be compared, and the preset absolute tolerance is Abto. The relative difference of the numerical fields of the two transactions to be compared is calculated, and the relative difference is wherein is the relative difference, and the preset configuration threshold is Coth, and then the similarity of the numerical fields of the two transactions to be compared is wherein 1 represents that the numerical fields of the two transactions are identical, 0 represents that the numerical fields of the two transactions are not identical;

[0027] For the date fields, the method of tolerable range similarity evaluation is as follows:

[0028] The maximum tolerable date offset Maxtdo is configured, and the similarity of the date fields is calculated by using a decay function, with the expression wherein is the similarity of the date fields, and are the values of the same date field of the two transactions to be compared, and the preset tolerance threshold is Toth. If is greater than or equal to the tolerance threshold Toth, it represents that the date fields of the two transactions are identical, and if is less than the tolerance threshold Toth, it represents that the date fields of the two transactions are not identical.

[0029] In a preferred embodiment, after obtaining the structured standardized transaction confirmation data, a floating interest rate cash flow prediction model is constructed based on the content of the standardized fields for the OTC derivative transaction records involving floating interest rates, the floating interest rate cash flow prediction model takes the interest accrual date, maturity date, nominal amount, payment frequency, interest rate benchmark, interest rate spread, and reset frequency in the transaction confirmation data as input parameters, and calculates the cash flow based on real-time market data;

[0030] The start and end times of each interest accrual period are determined, the applicable interest rate value of the current period is calculated according to the interest rate benchmark and the current floating interest rate formula corresponding to each period, and the interest cash flow amount to be paid or received in each period is generated. The cash flow sequence output by the floating interest rate cash flow prediction model includes the start and end dates of each period, the direction of interest to be received or paid, the amount, and the currency;

[0031] The model output result is compared with the confirmation result returned by the counterparty, if there is an amount inconsistency, interest accrual period inconsistency or calculation logic obvious deviation, it is determined that there is a floating interest rate formula deviation or valuation logic inconsistency, then the verification process is triggered, the transaction is marked as needing to be reviewed, and is pushed to the manual intervention process for business personnel to check field identification, parameter calculation and market data source.

[0032] An OTC derivative life cycle management method, a unified transaction view is used to index a unified transaction identifier, and the same transaction data from different business systems before, during and after the transaction is collected and structured integrated. The unified transaction identifier is used to aggregate and identify the multiple forms of the same transaction in the whole process, and the transaction confirmation information, valuation parameters, accounting attributes, settlement status, and life cycle event content in each business system are field-unified and structured-mapped to form a unified data object containing transaction life cycle information. The unified data object is queried and subscribed through a unified transaction view interface;

[0033] Obtain the state change data of the target transaction, the state change data includes the update record of the transaction field, the operation instruction, the timestamp information and the transaction unique identifier, based on the preset event recognition rule, the state change data is matched and analyzed, whether it meets the triggering condition of a certain life cycle event is judged, if the preset condition is met, the corresponding event type is extracted, and a standardized event object is constructed, and the constructed event object is pushed to the unified transaction view.

[0034] In a preferred embodiment, the method for obtaining the intervention depth indicator is:

[0035] Based on the unified transaction view, the set of business systems participating in data processing in the current transaction link is identified, and the set is denoted as wherein, is the set of fields involved in the current transaction link, and m is the number of fields involved in the current transaction link, for each business system , is the set of fields involved in the current transaction link, and m is the number of fields involved in the current transaction link, for each business system and field , analyze the control ability of the business system to the field in the current transaction link, the control ability type includes generation, modification, read-only and no access, and the control value is defined by the function , wherein the control value represents the control value of the business system to the field , and the expression of the control value is , then for the business system , the intervention depth index is the weighted control ability average of the business system to the field set, and the calculation expression of the intervention depth index is , wherein is the intervention depth index, which is used to represent the control ability of the business system to the participating field;

[0036] The method for obtaining the data structure difference index is:

[0037] For each pair of business systems in the set of business systems participating in the current transaction link, collect the data structure definition of the field , including data type, interface code and field granularity, and define the difference score of any field between the business systems and is , and the calculation expression is , wherein is the data type difference, is the interface code difference, is the field granularity difference, and are the proportion coefficients of the data type difference , the interface code difference and the field granularity difference respectively, and and are both positive numbers;

[0038] The data type difference is used to evaluate whether the data types of the same field in two business systems are consistent, if the field data types are completely consistent, the data type difference is 1, and if the field type is incompatible, the data type difference isis 0;

[0039] interface coding difference The interface coding difference is used to evaluate the coding difference of the expression of the field in the interface protocol between the two systems. The calculation expression of the interface coding difference is , wherein, is the longest edit distance of the coding of the two field names, is the maximum value of the coding lengths of the two fields, and The interface coding difference is greater, the greater the interface coding difference is, and the interface coding difference is smaller, the smaller the interface coding difference is.

[0040] field granularity difference The field granularity difference is used to evaluate the difference in the expression granularity of the field, and the expression is , wherein, is the number of subfields of the field h corresponding to the business system q, is the number of subfields of the field h corresponding to the business system k, and the field granularity difference is greater, the greater the field splitting gap is, and the field granularity difference is smaller, the smaller the field splitting gap is.

[0041] In a preferred embodiment, the indicator data generated by comparing all participating business systems in the current transaction link, including the intervention depth indicator, the data structure difference indicator and the field integrity verification result, are used to calculate the automatic trust score by using a linear weighted function , and the calculation expression is , wherein, and are the weight coefficients of and respectively, and and are positive numbers, is the integrity verification result, if the abnormal identification processing mechanism determines that there is a missing key field, the integrity verification result is 0, otherwise, the integrity verification result is 1.

[0042] The preset trust threshold is Ceth, the calculated automatic trust score Ats is compared with the trust threshold Ceth, if the calculated automatic trust score Ats is less than the trust threshold Ceth, the current transaction record is marked as a transaction identifier loss state, based on the transaction identifier loss state, an artificial intervention process is triggered, the early warning transaction information is pushed to the artificial verification platform, and the intervention depth indicator, the data structure difference indicator and the field integrity verification result corresponding to the current transaction are attached.

[0043] When the manual intervention operation is completed, the automated trust score of the transaction is re-evaluated, and it is decided whether to resume the automated processing flow or continue the manual tracking processing according to the new score.

[0044] An OTC derivative lifecycle management system comprises a transaction identification construction module, a data analysis and standardization module, a floating interest rate verification module, a unified transaction view module, an index calculation module, a trust score module and a manual intervention triggering module.

[0045] The transaction identification construction module constructs a unified transaction identification for uniquely identifying an OTC derivative transaction based on predefined transaction fields, and the unified transaction identification uniquely identifies the same OTC derivative transaction across system flow.

[0046] The data analysis and standardization module structurally analyzes transaction confirmation data from different transaction source systems, identifies and extracts transaction fields, including but not limited to frequency fields, floating interest rate calculation formula fields, nominal amount fields, and converts each field to a standard format based on set field semantic mapping rules.

[0047] The floating interest rate verification module constructs a floating interest rate cash flow prediction model based on the analyzed standardized transaction confirmation data, and realizes double verification of the correctness of the floating interest rate formula and the consistency of the valuation by comparing the floating interest rate cash flow prediction model output result with the transaction counterparty confirmation result. If the verification is inconsistent, a verification process is triggered.

[0048] The unified transaction view module constructs a unified transaction view based on the unified transaction identification and the standardized transaction confirmation data. When a certain lifecycle event is recorded in any business system, the event is synchronized to other business systems through the unified transaction view interface, realizing cross-system state synchronization and consistency maintenance of transaction lifecycle events.

[0049] The index calculation module calculates the intervention depth index and the data structure difference index of each business system involved in the comparison in the current transaction link. The intervention depth index is used to measure the direct generation or modification ability of the system to the key field, and the data structure difference index is used to evaluate the heterogeneous degree of data format, interface standard and field granularity between systems.

[0050] The trust score module generates an automated trust score based on the intervention depth index, the data structure difference index and the field consistency comparison result. The automated trust score is used to quantify the reliability level of the transaction in the current transaction link to realize automatic processing.

[0051] An artificial intervention triggering module marks the transaction as a transaction identification loss state when the automated trustworthiness score is lower than a preset threshold, and triggers an artificial intervention process to avoid affecting subsequent life cycle processing procedures.

[0052] In the above technical solution, the present application provides technical effects and advantages:

[0053] The present application designs an automatic processing reliability verification mechanism for evaluating the reliability of automation capability before the key processing steps of life cycle management. Among them, the current transaction link is not a single operation link, but any key step in the unified transaction identification generation and life cycle processing procedure, such as: transaction data analysis, transaction field standardization, cash flow prediction modeling, life cycle event synchronization, etc. Before these steps, dynamically evaluate the intervention depth and data structure heterogeneity of each participating system in the step, and combine the field processing consistency to generate an automated trustworthiness score.

[0054] The automated trustworthiness score can discover potential information disconnection, structure difference, field analysis conflict and other risk problems in advance. When the score is low, the reliability of the current step of automatic processing is poor, and there may be a high failure or error probability, so an artificial intervention mechanism needs to be introduced to prevent data pollution or downstream state disorder caused by automatic processing errors.

[0055] The present application significantly enhances the stability, robustness and transparency of the cross-system life cycle management mechanism driven by the unified transaction identification, improves the system processing quality, reduces the chain effect of automatic error on downstream valuation, accounting and risk control systems, provides data basis for automatic reliability evaluation and artificial intervention, and improves the compliance and reliability of the entire derivative transaction management chain. BRIEF DESCRIPTION OF DRAWINGS

[0056] In order to more clearly illustrate the technical solutions in the embodiments of the present application or the prior art, the drawings needed in the embodiments will be briefly introduced. Obviously, the drawings in the following description are only some embodiments described in the present application, and other drawings can also be obtained by those skilled in the art based on these drawings.

[0057] Figure 1 The method flowchart of the present application.

[0058] Figure 2 The system module diagram of the present application. DETAILED DESCRIPTION

[0059] With reference to the drawings and embodiments of the present application, the technical solutions in the embodiments of the present application will be described clearly and completely. Obviously, the described embodiments are only a part of the embodiments of the present application, rather than all the embodiments. Based on the embodiments in the present application, all other embodiments obtained by those skilled in the art without creative work are within the scope of protection of the present application.

[0060] Embodiment 1: please refer to Figure 1 As shown in the figure, the present application is a method for managing the life cycle of an OTC derivative product, and the specific steps include:

[0061] Based on the predefined transaction field, a unified transaction identifier for uniquely identifying an OTC derivative product transaction is constructed, which uniquely identifies the same OTC derivative product transaction flowing across systems;

[0062] The transaction confirmation data from different transaction source systems are structurally parsed, transaction fields are identified and extracted, including but not limited to frequency field, floating interest rate calculation formula field, nominal amount field, and based on the set field semantic mapping rules, each field is converted to a standard format;

[0063] Based on the parsed standardized transaction confirmation data, a floating interest rate cash flow prediction model is constructed, and by comparing the floating interest rate cash flow prediction model output result with the transaction counterparty confirmation result, the correctness of the floating interest rate formula and the consistency of the valuation are verified, and if the verification is inconsistent, a verification process is triggered;

[0064] Based on the unified transaction identifier and the standardized transaction confirmation data, a unified transaction view is constructed, when a certain life cycle event is recorded in any business system, the event is synchronized to other business systems through the unified transaction view interface, realizing the cross-system state synchronization and consistency maintenance of the transaction life cycle event;

[0065] For each business system involved in the comparison, the intervention depth index and the data structure difference index in the current transaction link are calculated, the intervention depth index is used to measure the direct generation or modification ability of the system to the key field, and the data structure difference index is used to evaluate the heterogeneous degree of data format, interface standard and field granularity between systems;

[0066] Based on the intervention depth index, the data structure difference index and the field consistency comparison result, an automatic trustworthiness score is generated, which is used to quantify the reliability level of automatic processing of the transaction in the current transaction link;

[0067] If the automatic trustworthiness score is lower than the preset threshold, the transaction is marked as a transaction identifier loss state, and a manual intervention process is triggered to avoid affecting the subsequent life cycle processing process.

[0068] From the transaction confirmation data, transaction input data or transaction matching system, extract the fields required to constitute the transaction identification, which at least include but are not limited to one or more of the following: transaction counterparty identification, transaction effective date, expiration date, product type, nominal amount, transaction currency, quotation direction and quotation method, standardize the above fields, and use a hash function to perform a summary operation on the standardized field combination to generate a unified transaction identification;

[0069] For high similarity but not completely repeated transaction records, a configurable field weighting comparison mechanism is introduced to resolve conflicts of transaction records and ensure the consistency of the unified transaction identification;

[0070] The generated unified transaction identification is written as the primary key into the main transaction database, and a mapping relationship is established with the original transaction number. The unified transaction identification is synchronized to the downstream modules of the valuation system, risk control system and accounting system through the interface to realize cross-system consistency tracking;

[0071] Based on the abnormal identification processing mechanism, when the key field is missing, the transaction is marked as "transaction identification abnormal" state, and the review intervention process is triggered to avoid the influence of abnormal transaction identification on downstream life cycle processing.

[0072] Standardize the fields, in a preferred embodiment, all fields related to transaction time, including effective date, expiration date, reset date, are converted to "YYYYMMDD" format, for example, "2025-01-01" is converted to "20250101", where "YYYY" is the four-digit year, "MM" is the two-digit month, and "DD" is the two-digit date. When the month and date are less than two digits, zero is filled;

[0073] In the code format conversion processing, the coding type fields are uniformly checked and mapped and converted using a standardized code library, for example, "dollar", "USD", "usd" are uniformly mapped to "USD", and "LIBOR USD 3M", "3M USD-LIBOR" are uniformly mapped to "USD-LIBOR-3M";

[0074] For non-critical but used for hash generation fields, including quotation frequency, reset frequency, if there are null or missing cases, use the default placeholder "NA" to fill in, to avoid field missing resulting in hash result mismatch;

[0075] The standardized field combination is spliced into a single string in a predetermined order for hash summary operation, and the field splicing order follows a fixed template to ensure consistency;

[0076] It should be noted that the order of the single string fixed template for hash digest operation is set by the professional technicians in the field according to the business type;

[0077] performing a digest operation on the single string using the SHA-256 hash algorithm to generate a 256-bit hash value, the 256-bit hash value being a unified transaction identifier;

[0078] The transaction records with high similarity but not completely repeated in the OTC derivatives due to transaction rolling reset, re-confirmation or multi-system concurrent entry are difficult to be uniformly identified. A configurable field weighting comparison mechanism is designed for conflict detection and similarity analysis of transaction records before generating a unified transaction identifier.

[0079] The logic for conflict resolution of transaction records with high similarity but not completely repeated by introducing a configurable field weighting comparison mechanism is as follows:

[0080] The comparison field set is preset by the business system administrator, including but not limited to: counterparty, transaction type, transaction start date, transaction end date, nominal amount, floating rate definition, frequency, currency pair, transaction direction, contract identifier code. For each comparison field, a corresponding weight value is assigned to represent the influence of the field in the overall similarity judgment. Among them, counterparty, transaction type, floating rate definition, frequency, currency pair, transaction direction and contract identifier code belong to text fields, nominal amount is a numerical field, and transaction start date and transaction end date belong to date fields.

[0081] For the two transactions to be compared, the field similarity is evaluated by extracting the field values respectively. The edit distance similarity is used for text fields, the absolute difference and relative difference double threshold similarity is used for numerical fields, and the tolerable range similarity is used for date fields.

[0082] After completing the field similarity evaluation, the field weight , wherein is the set of preset field weights, is the weight of each field in the set, i is the field serial number, and t is the total number of fields. The field similarity is weighted and aggregated, wherein is the set of field similarities, is the field similarity, the overall transaction similarity is calculated, and the calculation expression is , wherein is the overall transaction similarity.

[0083] The resolution threshold is set to Dith. If the overall transaction similarity calculated is If the similarity degree is greater than or equal to the resolution threshold Dith, it is determined that the two transactions to be compared are the same transaction logic instance, and the transaction record with the latest modification time is automatically saved. If the similarity degree is less than the resolution threshold Dith, it is determined that the two transactions to be compared are independent transactions, and are not merged, and an abnormal identification processing mechanism is used to avoid abnormal problems.

[0084] It should be noted that the weight value is adjusted by a person skilled in the art according to the transaction variety, scene or business department dimension, and the weight value is positive.

[0085] The transaction counterparty identifier is, for example, an LEI code, the product type is, for example, an interest swap, a forward exchange, an option, etc., the standardized processing includes date format unification, code format conversion, null value filling, a hash function such as SHA-256, a transaction record with high similarity but not complete repetition, for example, a rolled-over reset swap, an original transaction number including a pre-system ID and a confirmation number, and an encoding type field such as a currency pair, a reference interest rate and a transaction counterparty identifier.

[0086] In the embodiment of the present application, an abnormal identification processing mechanism is provided for possible abnormal situations in the generation of the unified transaction identifier, so as to guarantee the accuracy of the generated identifier and the stability of the life cycle management.

[0087] The abnormal situation is the absence of a key field. Before the generation of the unified transaction identifier, the integrity of each field is checked. The key fields include the transaction counterparty identifier, the transaction start date and the nominal amount. If any key field is filled with a default placeholder "NA", the transaction record is marked as an abnormal transaction identifier state, and the fields required for the transaction identifier are re-extracted from the transaction confirmation data, the transaction input data or the transaction matching system, and the integrity is checked. If the fields are completed, the standardization and the generation process of the unified transaction identifier are re-executed, and the state is corrected from the abnormal transaction identifier to the normal transaction identifier. If the integrity check fails, a manual review process is entered, and the operator is prompted to confirm the field value or make a decision on the transaction attribution. When the transaction record is determined to be invalid, it is marked as an unusable transaction identifier state and is excluded from the life cycle management path.

[0088] The method for evaluating the similarity degree of the text field using the edit distance is as follows:

[0089] For the texts of the two transactions to be compared, the minimum number of operations required to make them completely consistent through insertion, deletion or replacement operations is denoted as Ded. The similarity degree of the text field is calculated according to the maximum length Lmax of the text, and the calculation expression is , wherein is the similarity degree of the text field, and the maximum length Lmax of the text is the maximum length of the two texts participating in the comparison. 1 represents that the text fields of the two transactions are completely consistent;

[0090] The method for evaluating the similarity of the numerical fields by using the absolute difference and the relative difference is as follows:

[0091] The absolute difference of the numerical fields of the two transactions to be compared is calculated, and the absolute difference is wherein, is the absolute difference, and are the values of the same numerical field of the two transactions to be compared, and the preset absolute tolerance is Abto. The relative difference of the numerical fields of the two transactions to be compared is calculated, and the relative difference is wherein, is the relative difference, and the preset configuration threshold is Coth. Therefore, the similarity of the numerical fields of the two transactions to be compared is wherein, 1 represents that the numerical fields of the two transactions are consistent, 0 represents that the numerical fields of the two transactions are inconsistent.

[0092] The method for evaluating the similarity of the date fields is as follows:

[0093] The maximum tolerable date offset Maxtdo is configured, and the similarity of the date fields is calculated by using a decay function, and the calculation expression is wherein, is the similarity of the date fields, and are the values of the same date field of the two transactions to be compared, and the preset tolerance threshold is Toth. If is greater than or equal to the tolerance threshold Toth, it indicates that the date fields of the two transactions are consistent. If is less than the tolerance threshold Toth, it indicates that the date fields of the two transactions are inconsistent.

[0094] The field similarity evaluation can realize the semantic-level corresponding relationship identification of the key fields between different systems, and overcome the obstacles caused by the inconsistent field naming, structural level difference, different naming habits, etc., thereby providing accurate basis for the field matching and semantic mapping.

[0095] Through the similarity evaluation, the fields that are logically equivalent but have different names or formats are identified, the intelligent mapping and fusion of the fields across systems are realized, and the data integrity and consistency of the subsequent life cycle management are improved.

[0096] The quantitative result of the field similarity can be used as an important input for the consistency comparison of the fields, which is helpful for accurately determining whether two systems have the ability to losslessly synchronize a certain business field, and thereby guiding the calculation of the credibility score.

[0097] When the field similarity is lower than the preset threshold, the system can issue a warning and trigger a manual verification process, thereby avoiding problems such as data loss, transaction accounting errors, or life cycle breaks caused by mismatched fields.

[0098] The transaction confirmation data from multiple source systems is received, the transaction confirmation data is parsed, the transaction fields are extracted, the extracted transaction fields are classified and standardized, a field semantic mapping rule library is preset, the transaction fields are mapped and converted with the unified field model in combination with transaction rules and historical transaction patterns, and after the mapping and conversion of the transaction fields, the output is in the data structure format of the unified field model.

[0099] The transaction fields are mapped and converted with the unified field model, for example, “Tenor” and “Term to Maturity” are merged into “transaction term”, and “Notional” and “Nominal Amount” are merged into “nominal principal”;

[0100] The unified field model is based on business research and various derivative product master agreement provisions, and a set of standard field collection is abstracted, including but not limited to counterparty identification, transaction effective date, expiration date, product type, nominal amount, transaction currency, quotation direction and quotation method. The unified field model serves as the basic structure for field semantic identification and mapping, and sets the field name, field type, field meaning, business category, and semantic correspondence with each source system field. In the field semantic identification and mapping process, based on the pre-defined field semantic mapping rules, the field name, context information and field value type in the source system transaction confirmation data are identified and mapped to the target field in the unified field model, and converted to a standardized format for subsequent processing module identification and calling.

[0101] It should be noted that the source system includes the pre-transaction system, the middle office confirmation system, the counterparty platform, and the third-party confirmation agency, etc. The format of the transaction confirmation data includes JSON, XML, Excel, PDF, etc.

[0102] The field naming, format and granularity used by different systems differ, making it difficult to unify transaction data. Through semantic identification and mapping mechanism, the standardization of fields is achieved, improving the compatibility and processing efficiency of different source systems. Without unified field standards, there may be deviations in valuation, risk calculation or state synchronization. Field parsing and unification are achieved from the source, enhancing the stability of downstream processing. In the traditional life cycle processing process, manual identification and comparison of field meanings are relied on, which is inefficient. Through automatic semantic identification and standard mapping, the automation level is improved, providing basic data support for abnormal identification and credibility scoring.

[0103] After obtaining the structured and standardized transaction confirmation data, for the OTC derivative transaction records involving floating interest rates, a floating interest rate cash flow prediction model is constructed based on the content of the standardized fields. The floating interest rate cash flow prediction model takes the interest accrual date, maturity date, nominal amount, payment frequency, interest rate benchmark, interest rate spread, and reset frequency in the transaction confirmation data as input parameters, and calculates the cash flow based on real-time market data;

[0104] The start and end times of each interest accrual period are determined, the applicable interest rate value of the current period is calculated based on the interest rate benchmark and the current floating interest rate formula corresponding to each period, and the interest cash flow amount to be paid or received in each period is generated. The cash flow sequence output by the floating interest rate cash flow prediction model includes the start and end dates of each period, the direction of interest payment or receipt, the amount, and the currency;

[0105] The model output results are compared with the confirmation results returned by the counterparty. If there is a difference in the amount, the interest accrual period, or the calculation logic, it is determined that there is a floating interest rate formula deviation or inconsistent valuation logic, and the verification process is triggered. The transaction is marked as needing review and pushed to the manual intervention process for business personnel to check field identification, parameter calculation, and market data sources.

[0106] The direct calculation method of the floating interest rate cash flow prediction model helps to discover valuation deviations or data synchronization errors at the system level, avoids post-transaction issues such as valuation difference disputes, accounting processing deviations, or risk calculation distortion, and enhances the consistency of OTC derivative transaction valuation and risk control capabilities.

[0107] Real-time market data includes Shibor, Libor, SOFR, etc., and the current floating interest rate formula is, for example, "the average SOFR value of the previous reset day + interest rate spread."

[0108] The unified transaction view takes a unified transaction identifier as an index to collect and structure the same transaction data from different business systems before, during, and after the transaction. The unified transaction identifier is used to aggregate and identify multiple forms of the same transaction in the whole process. The transaction confirmation information, valuation parameters, accounting attributes, settlement status, and life cycle event content in each business system are field-unified and structured mapped to form a unified data object containing transaction lifecycle information. The unified data object is queried and subscribed through the unified transaction view interface.

[0109] Obtaining state change data of a target transaction, the state change data including update records of transaction fields, operation instructions, timestamp information and a transaction unique identifier, performing matching analysis on the state change data based on a preset event identification rule, determining whether a triggering condition of a certain life cycle event is met, if the preset condition is met, extracting a corresponding event type, and constructing a standardized event object, and pushing the constructed event object to a unified transaction view.

[0110] Through the construction of the unified transaction view and the use of the unified transaction identifier throughout, different business systems no longer rely on inefficient means such as manual synchronization or file transfer, but realize automatic synchronization through structured interfaces between systems, significantly improving the efficiency of life cycle event transmission. When multiple systems process life cycle events based on their own data copies, state synchronization problems are prone to occur, such as valuation overflow caused by the valuation system not updating the early termination state. The unified transaction view ensures that all systems process based on the same standard transaction object, avoiding logical conflicts caused by data fragmentation. By exposing the unified transaction view interface, newly connected systems can participate in transaction life cycle collaborative processing according to the standard protocol, enhancing system scalability and modular deployment capabilities.

[0111] Different business systems such as transaction entry systems, valuation systems, accounting systems, risk systems, confirmation systems, unified transaction view interfaces such as unified API interfaces and event subscription channels, life cycle events including reset notifications, option exercise, early termination, margin replenishment, transaction splitting, transaction state changes such as value changes of transaction state fields, updates of specific business fields, and event objects including unified transaction identifiers, event types, event timestamps, event source system identifiers, and event impact fields.

[0112] Event identification rules are based on field logic, such as "state changes from Active to Terminated", time nodes such as "expiration date is today", and combination logic such as "state change + amount field clear", state change data can come from interface call records, database change logs, middleware message queues, etc., standardized event objects use structured data format and have unique traceability.

[0113] Extracting all participating business systems in the current transaction stage, including transaction confirmation systems, valuation systems, accounting systems, and risk systems, extracting the key transaction field set generated or processed by each participating system in the current stage, recording the operation permissions of the system for the key fields such as generation, modification, transmission or read-only, and calculating the intervention depth index of the system in the current transaction stage according to the operation ability of the system for the key fields.

[0114] For any interaction between two systems, collect the data structure information on key fields, including field format, data type, naming specification, nesting level, and calculate the data structure difference index between the two systems.

[0115] By quantifying the intervention depth of the system on the field, it can accurately identify which system triggered the key field exception, narrow down the problem range, and through the structure difference index, it can pre-evaluate the consistency risk before the automatic call of the system data interface, and reduce the automatic failure rate.

[0116] The method for obtaining the intervention depth index is:

[0117] Based on the unified transaction view, identify the set of each business system participating in data processing in the current transaction link, and record the set as , wherein is the set of each business system, p is the number of business systems, determine the field set involved in the current transaction link, and record it as , wherein is the field set involved in the current transaction link, m is the number of fields involved in the current transaction link, for each business system and field , analyze the control ability of the business system on the field in the current transaction link, the control ability type includes generation, modification, read-only and no access, and the control value is defined by the function , wherein the control value represents the control value of the business system on the field , and the expression of the control value is , then for the business system , the intervention depth index is the weighted control ability average of the field set, and the intervention depth index is calculated by the expression , wherein is the intervention depth index, which is used to represent the control ability of the business system on the participating field.

[0118] The introduction of the intervention depth index is used to quantify the degree of dominance of a business system in the transaction life cycle in forming and controlling data, and reflects the influence of its credibility on the automatic result.

[0119] The method for obtaining the data structure difference index is:

[0120] For each pair of business systems in the set of business systems participating in the current transaction link, collect the data structure definition of the field , including data type, interface code and field granularity, define any field in the business system and The difference between them was scored as follows The calculation expression is: ,in, Due to differences in data types, Due to differences in interface encoding, Due to differences in field granularity, and Differences between data types Interface coding differences Differences in field granularity The proportionality coefficient, and and All are positive numbers;

[0121] Data type differences This is used to evaluate whether the data type used for the same field is consistent in two business systems. If the data types of the fields are completely consistent, then the data type difference is considered. The value is 1. If the field type is incompatible, then the data type difference is considered. The value is 0;

[0122] Interface coding differences This is used to evaluate the encoding differences in how fields are represented in the interface protocols between two systems; interface encoding differences. The calculation expression is as follows In the formula, This represents the longest edit distance between the encodings of two field names, which is the maximum value of the encoding lengths of the two fields. Interface coding differences The larger the value, the greater the difference in interface encoding. The smaller the value, the smaller the interface encoding difference;

[0123] Field granularity differences Used to evaluate differences in the granularity of field representation, the expression is: ,in, This represents the number of subfields of field h corresponding to field q in the business system. The number of subfields of field h corresponding to field k in the business system, and the difference in field granularity. The larger the value, the greater the difference in field splitting and the greater the difference in field granularity. The smaller the value, the smaller the difference in field splitting.

[0124] To measure the granularity differences of the same field in different business systems, based on the interface field metadata or field structure definition document maintained by each system, the number of subfields of each field is parsed. If a field is a composite type or split into multiple subfields in the system, the number of subfields of the field is the number of its constituent items.

[0125] For the fields shared between multiple business systems, set a field set , wherein represents the hth field of the field set, h is the field number, and h is a positive integer;

[0126] Data types such as float, string, datetime, etc., interface coding includes JSON, XML, CSV, field granularity such as daily, per-pen, or summary transmission, and The value is set by a person skilled in the art according to the type of business;

[0127] The data structure difference index is used to measure the structural heterogeneity in the data integration process across systems, identify interface docking, field inconsistency, and data parsing difficulty, etc. Problem source.

[0128] For the indicator data generated by all participating comparison business systems in the current transaction link, including the intervention depth index, the data structure difference index, and the field integrity check result, a linear weighted function is used to calculate the automatic trust score , the calculation expression is , wherein and are the weight coefficients of and , and and are positive numbers, is the integrity check result, if the abnormal identifier processing mechanism determines that there is a missing key field, the integrity check result is 0, otherwise, the integrity check result is 1;

[0129] The preset trust threshold is Ceth, the calculated automatic trust score Ats is compared with the trust threshold Ceth, if the calculated automatic trust score Ats is less than the trust threshold Ceth, the current transaction record is marked as a transaction identifier loss state, based on the transaction identifier loss state, the manual intervention process is triggered, the warning transaction information is pushed to the artificial verification platform, and the intervention depth index, the data structure difference index and the field integrity check result corresponding to the current transaction are attached.

[0130] When the manual intervention operation is completed, the automatic trust score of the transaction is re-evaluated, and it is decided whether to restore to the automatic processing flow or continue to follow the manual tracking process according to the new score.

[0131] The transaction identification loss state refers to that a current transaction lacks a unified identification basis or has a high-risk field difference, and cannot ensure the consistency of the processing behaviors of various business modules in the life cycle management system.

[0132] Through the above steps, when the automated credibility score is low, the risk transaction with inconsistent identification or heterogeneous data structure is timely labeled and identified, avoiding problems such as data mismatch, state drift or repeated account entry when the transaction continues to enter the subsequent life cycle processing link. The introduction of manual intervention process provides a guarantee basis for data consistency for subsequent links, improves the overall accuracy and reliability of cross-system collaborative processing, and at the same time can accumulate automated risk transaction samples to provide data support for subsequent model training and optimization of the system;

[0133] The credibility evaluation is embedded before the transaction information automated processing flow, which improves the confidence judgment ability of the system to the automated processing result. When low credibility of automation is found at a key step, intervention is made in advance to prevent errors from being transmitted to downstream systems, forming a quantifiable automated quality index, i.e., automated credibility score, which is convenient for system continuous optimization and manual intervention decision.

[0134] Embodiment 2: Please refer to Figure 2 As shown in the figure, the present application is a life cycle management system for over-the-counter derivatives, which comprises a transaction identification construction module, a data analysis and standardization module, a floating interest rate verification module, a unified transaction view module, an index calculation module, a credibility scoring module and a manual intervention triggering module.

[0135] The transaction identification construction module constructs a unified transaction identification for uniquely identifying over-the-counter derivative transactions based on predefined transaction fields. The unified transaction identification uniquely identifies the same over-the-counter derivative transaction flowing across systems.

[0136] The data analysis and standardization module performs structural analysis on transaction confirmation data from different transaction source systems, identifies and extracts transaction fields, including but not limited to frequency field, floating interest rate calculation formula field, nominal amount field, and converts each field to a standard format based on the set field semantic mapping rules.

[0137] The floating interest rate verification module constructs a floating interest rate cash flow prediction model based on the analyzed standardized transaction confirmation data, and realizes double verification of the correctness of the floating interest rate formula and the consistency of the valuation by comparing the floating interest rate cash flow prediction model output result with the transaction counterparty confirmation result. If the verification is inconsistent, a verification process is triggered.

[0138] The unified transaction view module constructs a unified transaction view based on the unified transaction identifier and the standardized transaction confirmation data, and when a certain life cycle event is recorded in any business system, the event is synchronized to other business systems through a unified transaction view interface, so as to realize cross-system state synchronization and consistency maintenance of the transaction life cycle event.

[0139] The index calculation module calculates the intervention depth index and the data structure difference index of each business system participating in comparison in the current transaction link, the intervention depth index is used to measure the direct generation or modification ability of the system to the key field, and the data structure difference index is used to evaluate the heterogeneous degree of data format, interface standard and field granularity between systems.

[0140] The credibility scoring module generates an automated credibility score based on the intervention depth index, the data structure difference index and the field consistency comparison result, and the automated credibility score is used to quantify the reliability level of automatic processing of the transaction in the current transaction link.

[0141] The manual intervention triggering module marks the transaction as a transaction identifier loss state when the automated credibility score is lower than a preset threshold, and triggers a manual intervention process to avoid affecting the subsequent life cycle processing process.

[0142] The present application designs an automated processing reliability verification mechanism for evaluating the reliability of automated capabilities before the key processing steps of life cycle management. Among them, the current transaction link is not a single operation link, but any key step in the unified transaction identifier generation and life cycle processing process, such as: transaction data analysis, transaction field standardization, cash flow prediction modeling, life cycle event synchronization, etc. Before these steps, dynamically evaluate the intervention depth and data structure heterogeneity of each participating system in the step, and generate an automated credibility score combined with the field processing consistency.

[0143] The automated credibility score can detect potential information disconnection, structural difference, field parsing conflict and other risk problems in advance. When the score is low, the reliability of the current step of automated processing is poor, and there may be a high failure or error probability, so a manual intervention mechanism needs to be introduced to prevent data pollution or downstream state disorder caused by automatic processing errors.

[0144] The present application significantly enhances the stability, robustness and transparency of the cross-system life cycle management mechanism driven by the unified transaction identifier, improves the system processing quality, reduces the chain effect of automated errors on downstream valuation, accounting and risk control systems, provides data basis for automated reliability evaluation and manual intervention, and improves the compliance and reliability of the entire derivative transaction management chain.

[0145] The above formulas are all de-dimensioned to calculate the numerical values, the formulas are obtained by collecting a large amount of data to simulate a formula of the most recent real situation, and preset parameters in the formulas are set by a person skilled in the art according to actual conditions.

[0146] Those skilled in the art can clearly understand that, for the convenience and brevity of description, the specific working process of the system described above can refer to the corresponding process in the foregoing method embodiments, and will not be described here.

[0147] The above is only a specific implementation of the present application, but the protection scope of the present application is not limited thereto, any person skilled in the art can easily think of changes or replacements within the technical range disclosed by the present application, which should be covered within the protection scope of the present application. Therefore, the protection scope of the present application should be subject to the protection scope of the claims.

Claims

1. An off-exchange derivative lifecycle management method, characterized by, The specific steps include: Based on the pre-defined transaction field, a unified transaction identification for identifying the over-the-counter derivative transaction is constructed, which uniquely identifies the same over-the-counter derivative transaction across system flow; Structural parsing is performed on the transaction confirmation data from different transaction source systems, transaction fields including frequency field, floating interest rate calculation formula field, nominal amount field are identified and extracted, and based on the set field semantic mapping rules, each field is converted to a standard format; Based on the parsed standardized transaction confirmation data, a floating interest rate cash flow prediction model is constructed, and by comparing the floating interest rate cash flow prediction model output result with the transaction counterparty confirmation result, the correctness of the floating interest rate formula and the consistency of the valuation are verified, and if the verification is inconsistent, a review process is triggered; Based on the unified transaction identification and the standardized transaction confirmation data, a unified transaction view is constructed, when a certain life cycle event is recorded in any business system, the event is synchronized to other business systems through the unified transaction view interface, realizing cross-system state synchronization and consistency maintenance of transaction life cycle events; For each business system involved in comparison, the intervention depth index and the data structure difference index in the current transaction link are calculated, the intervention depth index is used to measure the direct generation or modification ability of the system to the key field, and the data structure difference index is used to evaluate the heterogeneous degree of data format, interface standard and field granularity between systems; Based on the intervention depth index, the data structure difference index and the field consistency comparison result, an automatic trustworthiness score is generated, which is used to quantify the reliability level of automatic processing of the transaction in the current transaction link; If the automatic trustworthiness score is lower than the preset threshold, the transaction is marked as a transaction identification loss state, and a manual intervention process is triggered to avoid affecting the subsequent life cycle processing process.

2. The method of claim 1, wherein, From the transaction confirmation data, transaction input data or transaction matching system, the fields required to constitute the transaction identification are extracted, which at least include one or more of the following: transaction counterparty identification, transaction effective date, expiration date, product type, nominal amount, transaction currency, quotation direction and quotation method, the above fields are standardized, and a hash function is used to perform digest operation on the standardized field combination to generate a unified transaction identification; For high similarity but not completely repeated transaction records, a configurable field weighted comparison mechanism is introduced to resolve conflicts between transaction records and ensure the consistency of the unified transaction identification; The generated unified transaction identification is written into the main transaction database as the primary key, and a mapping relationship with the original transaction number is established, and the unified transaction identification is synchronized to the valuation system, risk control system and accounting system downstream modules through the interface, realizing cross-system consistency tracking; Based on the abnormal identification processing mechanism, when the key field is missing, the transaction is marked as "transaction identification abnormal" state, and a review intervention process is triggered to avoid the influence of abnormal transaction identification on downstream life cycle processing.

3. The method of claim 2, wherein, The logic of introducing a configurable field weighted comparison mechanism to resolve conflicts between transaction records is: The comparison field set is preset by a business system administrator, including: a counterparty, a transaction type, a transaction start date, a transaction end date, a nominal amount, a floating interest rate definition, a frequency, a currency pair, a transaction direction, and a contract identification code, a corresponding weight value is assigned to each comparison field, used to represent the influence of the field in the overall similarity judgment, wherein the counterparty, the transaction type, the floating interest rate definition, the frequency, the currency pair, the transaction direction, and the contract identification code belong to text fields, the nominal amount is a numerical field, and the transaction start date and the transaction end date belong to date fields; For the two transactions to be compared, the field values are extracted for field similarity evaluation, the edit distance similarity evaluation is used for the text field, the absolute difference and relative difference double threshold similarity evaluation is used for the numerical field, and the tolerable range similarity evaluation is used for the date field; After completing the field similarity assessment, based on the preset field weights... ,in For a set of preset field weights, Let i be the field index and t be the total number of fields in the set, and let t be the weight of each field. Perform weighted aggregation, where... For the set of similarity scores for each field, To calculate the overall transaction similarity based on field similarity, the calculation expression is as follows: In the formula, For overall transaction similarity; Dith, if the calculated overall transaction similarity Dith, then the two transactions to be compared are determined as the same transaction logic instance, and the transaction record with the latest modification time is automatically saved. If the calculated overall transaction similarity Dith, then the two transactions to be compared are determined as the same transaction logic instance, and the transaction record with the latest modification time is automatically saved. If the calculated overall transaction similarity 4. The method of claim 3, wherein, The method for using the edit distance similarity evaluation for the text field is as follows: For the two transaction texts to be compared, the minimum number of operations (insertion, deletion or replacement) required to make them identical is denoted as Ded, and the similarity of the text fields is calculated according to the maximum length Lmax of the texts, with the expression , where is the similarity of the text fields, and the maximum length Lmax of the texts is the maximum length of the two texts involved in the comparison, where 1 represents that the text fields of the two transactions are completely identical. The method for using the absolute difference and relative difference double threshold similarity evaluation for the numerical field is as follows: an absolute difference is calculated for the numerical fields of the two transactions to be compared, the absolute difference is wherein, the absolute difference is and the values of the same numerical fields of the two transactions to be compared, a preset absolute tolerance is Abto, a relative difference is calculated for the numerical fields of the two transactions to be compared, the relative difference is wherein, the relative difference is wherein, 1 indicates that the numerical fields of the two transactions are consistent, 0 indicates that the numerical fields of the two transactions are inconsistent; The method for using the tolerable range similarity evaluation for the date field is as follows: A maximum tolerance date offset Maxtdo is configured, and a similarity of the date field is calculated by using a decay function, and the calculation expression is wherein, is the similarity of the date field, and are values of the same date field of two transactions to be compared, a preset tolerance threshold is Toth, if is greater than or equal to the tolerance threshold Toth, it indicates that the date fields of the two transactions are consistent, if is less than the tolerance threshold Toth, it indicates that the date fields of the two transactions are inconsistent.

5. The method of claim 1, wherein, After obtaining the structured standardized transaction confirmation data, for the over-the-counter derivative transaction records involving floating interest rates, a floating interest rate cash flow prediction model is constructed based on the standardized field content, the floating interest rate cash flow prediction model takes the interest accrual date, the maturity date, the nominal amount, the payment frequency, the interest rate benchmark, the interest rate spread, and the reset frequency in the transaction confirmation data as input parameters, and combines real-time market data to calculate the cash flow; The start and end times of each interest accrual period are determined, the applicable interest rate value of the current period is calculated according to the interest rate benchmark and the current floating interest rate formula of each period, and the interest cash flow amount to be paid or received in each period is generated, the cash flow sequence output by the floating interest rate cash flow prediction model includes the start and end dates of each period, the payment direction or the receiving direction, the amount, and the currency; The model output result is compared with the confirmation result returned by the counterparty, if there is an amount inconsistency, an interest accrual period inconsistency, or a calculation logic obvious deviation, it is determined that there is a floating interest rate formula deviation or an inconsistent valuation logic, and a verification process is triggered, the transaction is marked as a review state, and is pushed to a manual intervention process for field recognition, parameter calculation, and market data source checking by a business personnel.

6. The method of managing the life cycle of an off-exchange derivative according to claim 5, wherein, A unified transaction view is indexed by a unified transaction identifier, and the same transaction data from different business systems before, during, and after the transaction is collected and structuredly integrated, the unified transaction identifier is used to aggregate and identify the same transaction in the whole process, the transaction confirmation information, the valuation parameters, the accounting attributes, the settlement state, and the life cycle event content in each business system are field-unified and structuredly mapped to form a unified data object containing the whole life cycle information of the transaction, and the unified data object is queried and subscribed through a unified transaction view interface; Obtain the state change data of the target transaction, the state change data including update records of transaction fields, operation instructions, timestamp information and transaction unique identification, match and analyze the state change data based on preset event identification rules, judge whether it meets the triggering conditions of a certain life cycle event, if the preset conditions are met, extract the corresponding event type, and construct a standardized event object, and push the constructed event object to a unified transaction view.

7. The method of managing the life cycle of an off-exchange derivative according to claim 1, wherein, The method for obtaining the intervention depth index is: A set of business systems participating in data processing in the current transaction link is identified based on the unified transaction view, and the set is denoted as wherein, is the set of business systems, p is the number of business systems, a field set involved in the current transaction link is determined and denoted as wherein, is the field set involved in the current transaction link, m is the number of fields involved in the current transaction link, for each business system and field , the control ability of the business system to the field in the current transaction link is analyzed, the control ability type includes generation, modification, read-only and no access, and the control value is defined by a function wherein, the control value represents the control value of the business system to the field , and the expression of the control value is then for the business system , the intervention depth index is the weighted control ability average of the business system to the field set, and the calculation expression of the intervention depth index is wherein, is the intervention depth index, used to represent the control ability of the business system to the participating field; The method for obtaining the data structure difference index is: For each pair of business systems in the business system set participating in the current transaction link , collect the data structure definition of the field , including data type, interface code and field granularity, define the difference score of any field between the business systems and as , and the calculation expression is , wherein is the data type difference, is the interface code difference, is the field granularity difference, and are the proportional coefficients of the data type difference , the interface code difference and the field granularity difference respectively, and and are positive numbers; Data type difference Data type difference is used to assess whether the data types of the same field in two business systems are consistent. If the data types of the field are completely consistent, the data type difference is 1, if the field type is an incompatible type, the data type difference is 0; interface coding difference An interface coding difference is used to assess the coding difference in the way a field is represented in the interface protocols of two systems. The computational expression for the interface coding difference is where is the longest edit distance between the two field name encodings, is the maximum of the two field encoding lengths, and The interface coding difference is larger, the larger the interface coding difference is, and the interface coding difference is smaller, the smaller the interface coding difference is. Field granularity difference For evaluating the difference of field expression granularity, the expression is wherein, is the number of sub-fields of field h corresponding to business system q, is the number of sub-fields of field h corresponding to business system k, the field granularity difference The larger the field granularity difference is, the larger the field split gap is. The smaller the field granularity difference is, the smaller the field split gap is.

8. The method of managing the life cycle of an off-exchange derivative according to claim 7, wherein, For all the participating business systems in the current transaction link, the generated index data is compared, including the intervention depth index, the data structure difference index and the field integrity check result, and a linear weighting function is used to calculate the automatic trust score , the calculation expression is , wherein, and are weight coefficients of and respectively, and and are positive numbers, is the integrity check result, if the abnormal identification processing mechanism determines that there is a missing key field, the integrity check result is 0, otherwise, the integrity check result is 1; The preset trust threshold is Ceth, the calculated automated trust score Ats is compared with the trust threshold Ceth, if the calculated automated trust score Ats is less than the trust threshold Ceth, the current transaction record is marked as a transaction identification loss state, based on the transaction identification loss state, an artificial intervention process is triggered, and warning transaction information is pushed to an artificial verification platform, and the intervention depth index, the data structure difference index and the field integrity verification result corresponding to the current transaction are attached; When the artificial intervention operation is completed, the automated trust score of the transaction is re-evaluated, and it is decided whether to restore to the automated processing process or to continue the artificial tracking processing according to the new score.

9. An OTC derivative lifecycle management system for implementing the management method of any one of claims 1 to 8, characterized in that, It includes a transaction identification construction module, a data analysis and standardization module, a floating interest rate verification module, a unified transaction view module, an index calculation module, a trust score module and an artificial intervention triggering module; The transaction identification construction module constructs a unified transaction identification for uniquely identifying an over-the-counter derivative transaction based on a predefined transaction field, and the unified transaction identification uniquely identifies the same over-the-counter derivative transaction flowing across systems; The data analysis and standardization module structurally analyzes transaction confirmation data from different transaction source systems, identifies and extracts transaction fields, including frequency fields, floating interest rate calculation formula fields, nominal amount fields, and converts each field to a standard format based on a set field semantic mapping rule; The floating interest rate verification module constructs a floating interest rate cash flow prediction model based on the analyzed standardized transaction confirmation data, and realizes double verification of the correctness of the floating interest rate formula and the consistency of the valuation by comparing the floating interest rate cash flow prediction model output result with the transaction counterparty confirmation result, if the verification is inconsistent, the verification process is triggered; The unified transaction view module constructs a unified transaction view based on the unified transaction identification and the standardized transaction confirmation data, when a certain life cycle event is recorded in any business system, the event is synchronized to other business systems through a unified transaction view interface, realizing cross-system state synchronization and consistency maintenance of transaction life cycle events; The index calculation module calculates the intervention depth index and the data structure difference index of each business system participating in comparison in the current transaction link, the intervention depth index is used to measure the direct generation or modification ability of the system to the key field, and the data structure difference index is used to evaluate the heterogeneous degree of data format, interface standard and field granularity between systems; A credibility scoring module generates an automated credibility score based on the intervention depth indicator, the data structure difference indicator, and the field consistency comparison result, the automated credibility score being used to quantify a reliability level of the transaction in achieving automatic processing at a current transaction link; An artificial intervention triggering module labels the transaction as a transaction identification loss state when the automated credibility score is lower than a preset threshold, and triggers an artificial intervention process to avoid affecting a subsequent life cycle processing process.

Images