Off-site derivative life cycle management system and method

Abstract

The invention discloses an off-site derivative life cycle management system and method, and particularly relates to the technical field of off-site transactions, and the method specifically comprises the steps: constructing a unified transaction identifier for uniquely identifying off-site derivative transactions based on a predefined transaction field, carrying out the structural analysis of transaction confirmation data from different transaction source systems, and carrying out the analysis of the transaction confirmation data. Constructing a floating interest rate cash flow prediction model, comparing model output with a transaction opponent confirmation result for verification, constructing a unified transaction view, realizing cross-system state synchronization and consistency maintenance of a transaction life cycle event, calculating an intervention depth index and a data structure difference index of a business system in a current transaction link, and calculating a transaction result. And an automatic credibility score is generated to quantify the reliability level of the transaction for realizing automatic processing in the current transaction link, the credibility and necessity of manual intervention are improved through a reliability verification mechanism, and data pollution or downstream state disorder caused by wrong automatic processing is prevented.

Description

Technical Field

[0001] The present invention relates to the field of over-the-counter (OTC) trading technology, and more specifically, to an OTC derivatives lifecycle management system and method. Background Art

[0002] Existing OTC transactions are typically communicated and confirmed using free-form text, email, or phone calls. The varying representations of OTC derivatives lead to inconsistencies in transaction master data, confirmation data, and valuation data. The lack of a unified transaction anchor structure to track the status of OTC derivatives across all systems makes it difficult to directly convert the legal existence of OTC derivatives into digital tags for identification and status tracking. OTC derivatives are non-standardized and rely on manual entry of transaction terms. Even if the confirmation text is clear, there is still a possibility that the system will not be able to accurately extract special fields. Special fields, such as floating interest rate formulas, rely heavily on manual review.

[0003] In the current lifecycle management of over-the-counter derivatives, the interfaces between systems are heterogeneous and the understanding of fields varies greatly, making it difficult to perceive automation failures or errors. The degree of participation of each system at different stages of the lifecycle varies greatly, resulting in some processing being overly dependent on manual labor without a control mechanism. There is a lack of an effective pre-judgment mechanism to determine whether manual verification is necessary, resulting in an increase in the workload of manual intervention and a simultaneous increase in the probability of manual errors, which in turn affects the stability of the lifecycle management of over-the-counter derivatives.

[0004] In order to solve the above defects, a technical solution is now proposed. Summary of the Invention

[0005] The purpose of the present invention is to provide an over-the-counter derivatives lifecycle management system and method to solve the problems in the above-mentioned background technology.

[0006] To achieve the above objectives, the present invention provides the following technical solution: a method for managing the lifecycle of over-the-counter derivatives, comprising the following specific steps:

[0007] Based on predefined transaction fields, a unified transaction identifier is constructed for uniquely identifying OTC derivatives transactions. The unified transaction identifier uniquely identifies the same OTC derivatives transaction flowing across systems.

[0008] Perform structured parsing of transaction confirmation data from various transaction source systems, identifying and extracting transaction fields, including but not limited to frequency fields, floating rate calculation formula fields, and nominal amount fields, and converting each field into a standard format based on predefined field semantic mapping rules;

[0009] Based on the parsed standardized transaction confirmation data, a floating rate cash flow forecast model is constructed. By comparing the output of the floating rate cash flow forecast model with the counterparty's confirmation results, a dual verification of the correctness of the floating rate formula and the consistency of the valuation is achieved. If the verification is inconsistent, the verification process is triggered;

[0010] Based on unified transaction identification and standardized transaction confirmation data, a unified transaction view is constructed. When a lifecycle event is recorded in any business system, the event is synchronized to other business systems through the unified transaction view interface, achieving cross-system status synchronization and consistency maintenance of transaction lifecycle events.

[0011] For each business system involved in the comparison, calculate its involvement depth index and data structure difference index in the current transaction link. The involvement depth index is used to measure the system's ability to directly generate or modify key fields, and the data structure difference index is used to assess the degree of heterogeneity in data formats, interface standards, and field granularity between systems.

[0012] Based on the intervention depth indicator, data structure difference indicator and field consistency comparison results, an automation credibility score is generated, wherein the automation credibility score is used to quantify the reliability level of automatic processing of the transaction in the current transaction link;

[0013] If the automation credibility score is lower than a 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.

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

[0015] For transaction records that are highly similar but not completely duplicated, a configurable field weighted comparison mechanism is introduced to resolve conflicts and ensure the consistency of unified transaction identifiers.

[0016] The generated unified transaction ID is written into the main transaction database as the primary key and mapped to the original transaction number. The unified transaction ID is synchronized to the valuation system, risk control system, and accounting system downstream modules through the interface to achieve cross-system consistent tracking.

[0017] Based on the abnormal identification processing mechanism, when key fields are missing, the transaction is marked with the "transaction identification abnormality" status and the review 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 resolving conflicts between transaction records that are highly similar but not completely duplicated is as follows:

[0019] The business system administrator presets a set of comparison fields, including but not limited to: counterparty, transaction type, transaction start date, transaction end date, notional amount, floating rate definition, frequency, currency pair, transaction direction, and contract identification code. Each comparison field is assigned a corresponding weight value to indicate the field's influence in the overall similarity judgment. Among them, counterparty, transaction type, floating rate definition, frequency, currency pair, transaction direction, and contract identification code 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 aforementioned field values ​​are extracted for field similarity assessment. For text fields, the edit distance similarity is used; for numeric fields, the absolute difference and relative difference dual threshold similarity is used; and for date fields, the tolerable range similarity is used.

[0021] After completing the field similarity evaluation, based on the preset field weights ,in is a set of preset field weights, is the weight of each field in the set, i is the field number, t is the total number of fields, and the similarity of each field is Perform weighted aggregation, where is the similarity set of each field, For field similarity, calculate the overall transaction similarity. The calculation expression is , where is the overall transaction similarity;

[0022] Set the resolution threshold to Dith. If the calculated overall transaction similarity If the value is greater than or equal to the resolution threshold Dith, 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 calculated overall transaction similarity is If the difference is less than the resolution threshold Dith, the two transactions to be compared are determined to be independent transactions and will not be merged. An exception identification processing mechanism will be used to avoid abnormal problems.

[0023] In a preferred embodiment, the method of using edit distance similarity evaluation for text fields is:

[0024] For the texts of two transactions to be compared, the minimum number of operations required to make them completely consistent through insertion, deletion, or replacement is recorded as Ded. The similarity of the text fields is calculated based on the maximum length Lmax of the text. The calculation expression is: , where is the similarity of the text field, and the maximum text length Lmax is the longest of the two texts involved in the comparison. ,1 represents that the text fields of the two transactions are exactly the same;

[0025] The method for evaluating similarity using dual thresholds of absolute difference and relative difference for numerical fields is:

[0026] Calculate the absolute difference between the numerical fields of the two transactions to be compared. The absolute difference is ,in, is the absolute difference, and are the values ​​of the same numerical field of the two transactions to be compared. The preset absolute tolerance is Abto. The relative difference is calculated for the numerical fields of the two transactions to be compared. The relative difference is ,in, is the relative difference, the preset configuration threshold is Coth, then the similarity of the numerical fields of the two transactions to be compared is ,in, 1 indicates that the value fields of the two transactions are consistent. If it is 0, it means the value fields of the two transactions are inconsistent;

[0027] The method for evaluating the similarity of the tolerable range for date fields is:

[0028] Configure the maximum tolerated date offset Maxtdo and use the decay function to calculate the similarity of the date field. The calculation expression is: ,in, is the similarity of the date field, and are the values ​​of the same date field of the two transactions to be compared. The preset tolerance threshold is Toth. If If the date field of the two transactions is greater than or equal to the tolerance threshold Toth, it means that the date field of the two transactions is consistent. If it is less than the tolerance threshold Toth, it means that the date fields of the two transactions are inconsistent.

[0029] In a preferred embodiment, after obtaining structured standardized transaction confirmation data, a floating rate cash flow forecasting model is constructed based on the standardized field content for over-the-counter derivative transaction records involving floating rates. The floating rate cash flow forecasting model uses the value date, maturity date, notional amount, payment frequency, interest rate benchmark, interest rate spread, and reset frequency in the transaction confirmation data as input parameters, and combines real-time market data to perform cash flow estimation.

[0030] Determine the start and end dates of each interest calculation period, calculate the applicable interest rate for the period based on the corresponding interest rate benchmark and the current floating rate formula, and generate the interest cash flow amount payable or receivable for each period. The cash flow sequence output by the floating rate cash flow forecasting model includes the start and end dates, receivable or payable direction, amount, and currency of each period;

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

[0032] A method for managing the lifecycle of over-the-counter derivatives. A unified transaction view uses a unified transaction identifier as an index to aggregate 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 manifestations of the same transaction throughout the entire process. Transaction confirmation information, valuation parameters, accounting attributes, settlement status, and lifecycle event content in each business system are normalized and structured to form a unified data object containing information on the entire transaction lifecycle. This unified data object can be queried and subscribed to through a unified transaction view interface.

[0033] Obtain the status change data of the target transaction, which includes update records of transaction fields, operation instructions, timestamp information, and transaction unique identifier. Based on preset event recognition rules, perform matching analysis on the status change data to determine whether it meets the trigger conditions of a certain lifecycle event. If the preset conditions are met, extract the corresponding event type, construct a standardized event object, and push the constructed event object to the unified transaction view.

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

[0035] Based on the unified transaction view, the set of business systems involved in data processing in the current transaction link is identified and recorded as ,in, 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 isThe value is 0;

[0039] Interface encoding differences 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 , where Indicates the longest edit distance between two field name codes, which is the maximum value of the two field code lengths, and , interface encoding differences The larger the value, the greater the interface coding difference. The smaller the value, the smaller the interface coding difference.

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

[0041] In a preferred embodiment, a linear weighted function is used to calculate the automated credibility score for the indicator data generated by all the comparison business systems in the current transaction link, including the involvement depth indicator, data structure difference indicator and field integrity verification results. , the calculation expression is , where and They are and The weight coefficient of and are all positive numbers, The integrity check result is The value is 0, otherwise, the integrity check result The value is 1;

[0042] The preset trust threshold is Ceth. The calculated automation trust score Ats is compared with the trust threshold Ceth. If the calculated automation 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, and the warning transaction information is pushed to the manual verification platform, along with the intervention depth indicator, data structure difference indicator, and field integrity verification results corresponding to the current transaction;

[0043] After the manual intervention operation is completed, the transaction's automation credibility score is re-evaluated, and based on the new score, a decision is made whether to revert to the automated processing process or continue manual tracking and processing.

[0044] An OTC derivatives lifecycle management system, comprising a transaction identification building module, a data parsing and standardization module, a floating interest rate verification module, a unified transaction view module, an indicator calculation module, a credibility scoring module, and a manual intervention trigger module;

[0045] A transaction identifier construction module, which constructs a unified transaction identifier for uniquely identifying an OTC derivative transaction based on predefined transaction fields. The unified transaction identifier uniquely identifies the same OTC derivative transaction flowing across systems;

[0046] The data parsing and standardization module performs structured parsing on 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, and nominal amount fields, and converts each field into a standard format based on predefined field semantic mapping rules.

[0047] The floating rate verification module builds a floating rate cash flow forecast model based on parsed standardized transaction confirmation data. By comparing the output of the floating rate cash flow forecast model with the counterparty's confirmation results, it achieves dual verification of the correctness of the floating rate formula and the consistency of the valuation. If the verification is inconsistent, the verification process is triggered;

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

[0049] The indicator calculation module calculates the depth of involvement index and data structure difference index of each business system involved in the comparison in the current transaction process. The depth of involvement index is used to measure the system's ability to directly generate or modify key fields, and the data structure difference index is used to evaluate the degree of heterogeneity in data formats, interface standards, and field granularity between systems.

[0050] a credibility scoring module that generates an automated credibility score based on the intervention depth indicator, data structure difference indicator, and field consistency comparison results, wherein the automated credibility score is used to quantify the reliability level of the automatic processing of the transaction at the current transaction stage;

[0051] The manual intervention trigger module marks the transaction as a transaction identification loss state and triggers a manual intervention process when the automation credibility score is lower than a preset threshold, so as to avoid affecting the subsequent life cycle processing process.

[0052] In the above technical solution, the technical effects and advantages provided by the present invention are:

[0053] This application designs an automated processing reliability verification mechanism to evaluate the reliability of automation capabilities before key processing steps in lifecycle management. The current transaction link is not a single operation link, but refers to any key step in the unified transaction identification generation and lifecycle processing process, such as transaction data parsing, transaction field standardization, cash flow forecast modeling, lifecycle event synchronization, etc. Before these steps are executed, the depth of involvement of each participating system in that step and the degree of data structure heterogeneity are dynamically evaluated, and combined with the consistency of field processing, an automation credibility score is generated.

[0054] Automated credibility scoring can proactively identify potential risks such as information disjointedness, structural discrepancies, and field parsing conflicts. A low score indicates that the automated processing in the current step is unreliable and has a high probability of failure or error. Therefore, manual intervention is necessary to prevent erroneous automated processing from causing data contamination or downstream disruption.

[0055] This application significantly enhances the stability, robustness and transparency of the cross-system lifecycle management mechanism driven by unified transaction identification, improves the quality of system processing, reduces the chain reaction of automation errors on downstream valuation, accounting and risk control systems, provides data basis for automation reliability assessment and manual intervention, and improves the compliance and reliability of the entire derivatives transaction management chain. BRIEF DESCRIPTION OF THE DRAWINGS

[0056] In order to more clearly illustrate the embodiments of the present application or the technical solutions in the prior art, the following briefly introduces the drawings required for use in the embodiments. Obviously, the drawings described below are only some embodiments described in the present invention. For ordinary technicians in this field, other drawings can also be obtained based on these drawings.

[0057] Figure 1 Flow chart of the method of the present invention.

[0058] Figure 2 It is a system module diagram of the present invention. DETAILED DESCRIPTION

[0059] The following will provide a clear and complete description of the technical solutions in the embodiments of the present invention in conjunction with the accompanying drawings. Obviously, the described embodiments are only part of the embodiments of the present invention, not all of the embodiments. All other embodiments obtained by ordinary technicians in this field based on the embodiments of the present invention without making any creative efforts shall fall within the scope of protection of the present invention.

[0060] Example 1: Please refer to Figure 1 As shown, the present invention is a method for managing the life cycle of over-the-counter derivatives, which specifically includes the following steps:

[0061] Based on predefined transaction fields, a unified transaction identifier is constructed for uniquely identifying OTC derivatives transactions. The unified transaction identifier uniquely identifies the same OTC derivatives transaction flowing across systems.

[0062] Perform structured parsing of transaction confirmation data from various transaction source systems, identifying and extracting transaction fields, including but not limited to frequency fields, floating rate calculation formula fields, and nominal amount fields, and converting each field into a standard format based on predefined field semantic mapping rules;

[0063] Based on the parsed standardized transaction confirmation data, a floating rate cash flow forecast model is constructed. By comparing the output of the floating rate cash flow forecast model with the counterparty's confirmation results, a dual verification of the correctness of the floating rate formula and the consistency of the valuation is achieved. If the verification is inconsistent, the verification process is triggered;

[0064] Based on unified transaction identification and standardized transaction confirmation data, a unified transaction view is constructed. When a lifecycle event is recorded in any business system, the event is synchronized to other business systems through the unified transaction view interface, achieving cross-system status synchronization and consistency maintenance of transaction lifecycle events.

[0065] For each business system involved in the comparison, calculate its involvement depth index and data structure difference index in the current transaction link. The involvement depth index is used to measure the system's ability to directly generate or modify key fields, and the data structure difference index is used to assess the degree of heterogeneity in data formats, interface standards, and field granularity between systems.

[0066] Based on the intervention depth indicator, data structure difference indicator and field consistency comparison results, an automation credibility score is generated, wherein the automation credibility score is used to quantify the reliability level of automatic processing of the transaction in the current transaction link;

[0067] If the automation credibility score is lower than a 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.

[0068] Extracting fields required to form a transaction identifier from transaction confirmation data, transaction input data, or a transaction matching system, including at least one or more of the following: counterparty identifier, transaction effective date, expiration date, product type, notional amount, transaction currency, quote direction, and quote method; standardizing the above fields, and performing a digest operation on the standardized field combination using a hash function to generate a unified transaction identifier;

[0069] For transaction records that are highly similar but not completely duplicated, a configurable field weighted comparison mechanism is introduced to resolve conflicts and ensure the consistency of unified transaction identifiers.

[0070] The generated unified transaction ID is written into the main transaction database as the primary key and mapped to the original transaction number. The unified transaction ID is synchronized to the valuation system, risk control system, and accounting system downstream modules through the interface to achieve cross-system consistent tracking.

[0071] Based on the abnormal identification processing mechanism, when key fields are missing, the transaction is marked with the "transaction identification abnormality" status and the review intervention process is triggered to prevent abnormal transaction identification from affecting downstream lifecycle processing.

[0072] Standardize the fields. In a preferred embodiment, all fields related to transaction time, including effective date, expiration date, and reset date, are uniformly converted to the "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 day. If the month and day are less than two digits, zeros are added.

[0073] During the code format conversion process, a standardized code library is used to perform verification and mapping conversion on coding fields. For example, "USD", "USD", and "USD" are uniformly mapped to "USD", and "LIBOR USD 3M" and "3M USD-LIBOR" are uniformly mapped to "USD-LIBOR-3M".

[0074] For non-critical fields used for hash generation, including quote frequency and reset frequency, if there are empty or missing values, the default placeholder "NA" is used to fill them to avoid mismatching hash results due to missing fields;

[0075] The standardized field combination is spliced ​​into a single string in a preset order for hash digest calculation. The field splicing order follows a fixed template to ensure consistency.

[0076] It should be noted that the order of the fixed template of single character strings used for hash digest calculation is set by professionals in this 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, where the 256-bit hash value is a unified transaction identifier;

[0078] In over-the-counter derivatives, highly similar but not completely duplicate transaction records are difficult to uniformly identify due to transaction rollover resets, reconfirmations, or concurrent entry into multiple systems. A configurable field-weighted comparison mechanism is designed to perform conflict detection and similarity analysis on transaction records before generating a unified transaction identifier.

[0079] A configurable field weighted comparison mechanism is introduced. The logic for resolving conflicts between transaction records that are highly similar but not completely duplicated is as follows:

[0080] The business system administrator presets a set of comparison fields, including but not limited to: counterparty, transaction type, transaction start date, transaction end date, notional amount, floating rate definition, frequency, currency pair, transaction direction, and contract identification code. Each comparison field is assigned a corresponding weight value to indicate the field's influence in the overall similarity judgment. Among them, counterparty, transaction type, floating rate definition, frequency, currency pair, transaction direction, and contract identification code are text fields, notional amount is a numeric field, and transaction start date and transaction end date are date fields.

[0081] For the two transactions to be compared, the aforementioned field values ​​are extracted for field similarity assessment. For text fields, the edit distance similarity is used; for numeric fields, the absolute difference and relative difference dual threshold similarity is used; and for date fields, the tolerable range similarity is used.

[0082] After completing the field similarity evaluation, based on the preset field weights ,in is a set of preset field weights, is the weight of each field in the set, i is the field number, t is the total number of fields, and the similarity of each field is Perform weighted aggregation, where is the similarity set of each field, For field similarity, calculate the overall transaction similarity. The calculation expression is , where is the overall transaction similarity;

[0083] Set the resolution threshold to Dith. If the calculated overall transaction similarity If the value is greater than or equal to the resolution threshold Dith, 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 calculated overall transaction similarity is If the value is less than the resolution threshold Dith, the two transactions to be compared are considered independent and will not be merged. An exception identification mechanism will be used to avoid abnormal problems.

[0084] It should be noted that the weight values ​​are adjusted by professional technicians in this field according to the transaction type, scenario or business department, and the weight values ​​are all positive;

[0085] Counterparty identifiers such as LEI codes; product types such as interest rate swaps, forward foreign exchange, and options; standardization including date format unification, code format conversion, null value filling, hash functions such as SHA-256; highly similar but non-duplicate transaction records such as rolling reset swaps; original transaction numbers including the front-end system ID and confirmation number; and coded fields such as currency pair, reference rate, and counterparty identifier;

[0086] In the embodiment of the present invention, an abnormal identification processing mechanism is provided for abnormal situations that may occur during the generation of a unified transaction identification to ensure the accuracy of the generated identification and the stability of lifecycle management;

[0087] The abnormal situation is the missing of key fields. Before executing the unified transaction identification generation, the integrity of each field is checked. The key fields include counterparty identification, transaction start date, and nominal amount. If any key field is filled with the default placeholder "NA", the hash function summary budget process will not be entered, and the transaction record will be marked as a transaction identification abnormal state. The fields required to constitute the transaction identification are re-extracted from the transaction confirmation data, transaction input data or transaction matching system, and an integrity check is performed. If the fields are completed, the standardization and unified transaction identification generation process is re-executed, and the status is corrected from transaction identification abnormality to transaction identification normal; if the integrity check fails, the manual review process is entered, prompting the operator to confirm the field value or decide on the transaction ownership. When the transaction record is determined to be invalid, it is marked as a transaction identification unavailable state and excluded from the lifecycle management path.

[0088] The method for using edit distance similarity evaluation for text fields is:

[0089] For the texts of two transactions to be compared, the minimum number of operations required to make them completely consistent through insertion, deletion, or replacement is recorded as Ded. The similarity of the text fields is calculated based on the maximum length Lmax of the text. The calculation expression is: , where is the similarity of the text field, and the maximum text length Lmax is the longest of the two texts involved in the comparison. ,1 represents that the text fields of the two transactions are exactly the same;

[0090] The method for evaluating similarity using dual thresholds of absolute difference and relative difference for numerical fields is:

[0091] Calculate the absolute difference between the numerical fields of the two transactions to be compared. The absolute difference is ,in, is the absolute difference, and are the values ​​of the same numerical field of the two transactions to be compared. The preset absolute tolerance is Abto. The relative difference is calculated for the numerical fields of the two transactions to be compared. The relative difference is ,in, is the relative difference, the preset configuration threshold is Coth, then the similarity of the numerical fields of the two transactions to be compared is ,in, 1 indicates that the value fields of the two transactions are consistent. If it is 0, it means the value fields of the two transactions are inconsistent;

[0092] The method for evaluating the similarity of the tolerable range for date fields is:

[0093] Configure the maximum tolerated date offset Maxtdo and use the decay function to calculate the similarity of the date field. The calculation expression is: ,in, is the similarity of the date field, and are the values ​​of the same date field of the two transactions to be compared. The preset tolerance threshold is Toth. If If the date field of the two transactions is greater than or equal to the tolerance threshold Toth, it means that the date field of the two transactions is consistent. If it is less than the tolerance threshold Toth, it means that the date fields of the two transactions are inconsistent.

[0094] Field similarity assessment can identify semantic-level correspondences between key fields across different systems, addressing obstacles caused by inconsistent field naming, structural hierarchical differences, and different naming conventions, thereby providing an accurate basis for field matching and semantic mapping.

[0095] Through similarity assessment, logically equivalent fields with different names or formats are identified, enabling intelligent mapping and fusion of fields across systems, improving data integrity and consistency in subsequent lifecycle management.

[0096] The quantitative results of field similarity can serve as an important input for field consistency comparison, helping to accurately determine whether two systems are capable of losslessly and synchronously processing a business field, thereby guiding the calculation of credibility scores.

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

[0098] Receive transaction confirmation data from multiple source systems, parse the transaction confirmation data, extract transaction fields, classify and standardize the extracted transaction fields, preset a field semantic mapping rule library, combine transaction rules and historical transaction patterns, map and convert transaction fields to a unified field model, and output the mapped and converted transaction fields in the data structure format of the unified field model.

[0099] Map transaction fields to the unified field model. For example, merge "Tenor" and "Term to Maturity" into "Transaction Term" and merge "Notional" and "Nominal Amount" into "Nominal Principal."

[0100] Based on business research and the provisions of various derivative master agreements, the unified field model summarizes and abstracts a set of standard field sets, including but not limited to counterparty identification, transaction effective date, maturity 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. It sets the field name, field type, field meaning, business category and semantic correspondence with each source system field. In the process of field semantic identification and mapping, based on the pre-defined field semantic mapping rules, according to the field name, context information and field value type in the source system transaction confirmation data, the semantics of the source field are identified and mapped to the target field in the unified field model, and converted into a standardized format for recognition and calling by subsequent processing modules.

[0101] It should be noted that the source systems include the front-end trading system, the middle-office confirmation system, the counterparty platform, the third-party confirmation agency, etc. The formats of the transaction confirmation data include JSON, XML, Excel, PDF, etc.

[0102] Different systems use different field names, formats, and granularity, which makes it difficult to uniformly process transaction data. Through semantic recognition and mapping mechanisms, field standardization is achieved to improve the compatibility and processing efficiency of different source systems. Failure to unify field standards may lead to deviations in valuation, risk calculation, or status synchronization. Field parsing and unification are achieved from the source to enhance downstream processing stability. Traditional lifecycle processing relies on manual identification and comparison of field meanings, which is inefficient. Through automatic semantic recognition and standard mapping, the level of automation is improved to provide basic data support for anomaly 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] Obtain the status change data of the target transaction, which includes update records of transaction fields, operation instructions, timestamp information, and transaction unique identifier. Based on preset event recognition rules, perform matching analysis on the status change data to determine whether it meets the trigger conditions of a certain lifecycle event. If the preset conditions are met, extract the corresponding event type, construct a standardized event object, and push the constructed event object to the unified transaction view.

[0110] Through the construction of a unified transaction view and the consistent use of unified transaction identification, different business systems no longer rely on inefficient means such as manual synchronization or file transfer. Instead, they achieve automatic synchronization through structured interfaces between systems, significantly improving the efficiency of lifecycle event delivery. When multiple systems process lifecycle events based on their own data copies, state asynchrony problems are prone to occur. For example, the valuation system fails to update the early termination status, resulting in valuation overflow. The unified transaction view ensures that all systems are based on the same standard transaction object processing, avoiding logical conflicts caused by data fragmentation. By exposing the unified transaction view interface, newly connected systems can participate in the collaborative processing of the transaction lifecycle according to the standard protocol, enhancing the system's scalability and modular deployment capabilities.

[0111] Different business systems, such as transaction entry systems, valuation systems, accounting systems, risk systems, and confirmation systems, have unified transaction view interfaces, such as unified API interfaces and event subscription channels. Lifecycle events include reset notifications, option exercises, early terminations, margin calls, and trade splits. Transaction status changes include changes in the value of transaction status fields and updates to specific business fields. Event objects include 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 "status changes from Active to Terminated", time nodes such as "expiration date is today", and combination logic such as "status change + amount field cleared". Status change data can come from interface call records, database change logs, middleware message queues, etc. Standardized event objects use a structured data format and have unique traceability.

[0113] Extract all business systems involved in the current transaction, including the transaction confirmation system, valuation system, accounting system, and risk system. For each participating system, extract the key transaction fields generated or processed in the current process. Record the system's permissions to generate, modify, transmit, or read-only these key fields. Based on the system's ability to operate on these key fields, calculate the system's involvement depth index in the current transaction.

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

[0115] By quantifying the depth of system intervention in fields, we can accurately identify which system triggers key field anomalies and narrow the scope of the problem. Through structural difference indicators, we can pre-evaluate consistency risks before automated calls to system data interfaces and reduce automation failure rates.

[0116] The method to obtain the intervention depth index is:

[0117] Based on the unified transaction view, the set of business systems involved in data processing in the current transaction link is identified and recorded as ,in, is the set of various business systems, p is the number of business systems, and the field set involved in the current transaction link is determined and recorded as ,in, 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 fields , analyze the control capability of the business system on the fields in the current transaction link. The control capability types include generation, modification, read-only and no access. Define the control value, where the control value Represents the business system Field Control value, control value The expression 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 The calculation expression is ,in, It is an intervention depth indicator, which is used to indicate the control capability of the business system over the participating fields.

[0118] The introduction of the intervention depth indicator is used to quantitatively judge the degree of dominance of a business system in data formation and control during the transaction life cycle, reflecting its impact on the credibility of automation results.

[0119] The method to obtain the data structure difference index is:

[0120] For each pair of business systems in the business system set participating in the current transaction link , collect its pairs of fields Data structure definition, including data type, interface encoding and field granularity, defines any field In the business system and The difference score between , the calculation expression is ,in, For data type differences, Encoding differences for interfaces, is the field granularity difference, and The data type differences are , interface coding differences and field granularity differences The proportionality coefficient of and All are positive numbers;

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

[0122] Interface encoding differences 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 , where Indicates the longest edit distance between two field name codes, which is the maximum value of the two field code lengths, and , interface encoding differences The larger the value, the greater the interface coding difference. The smaller the value, the smaller the interface coding difference;

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

[0124] To measure the granularity differences of the same field in different business systems, the number of subfields of each field is parsed based on the interface field metadata or field structure definition document maintained by each system. 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 sub-items.

[0125] Set field sets for fields shared between multiple business systems ,in represents the hth field of the field set, where h is the field number and is a positive integer;

[0126] Data types include float, string, datetime, etc. Interface encoding includes JSON, XML, CSV, and field granularity such as whether to transmit by day, by item, or by summary. and The value of is set by professionals in this field according to the business type;

[0127] The data structure diversity index is used to measure the degree of structural heterogeneity across systems during the data integration process and to identify sources of problems such as interface docking, field inconsistency, and data parsing difficulty.

[0128] For the indicator data generated by all the business systems involved in the current transaction, including the involvement depth indicator, data structure difference indicator and field integrity verification results, a linear weighted function is used to calculate the automated credibility score. , the calculation expression is , where and They are and The weight coefficient of and are all positive numbers, The integrity check result is The value is 0, otherwise, the integrity check result The value is 1;

[0129] The preset trust threshold is Ceth. The calculated automation trust score Ats is compared with the trust threshold Ceth. If the calculated automation 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, and the warning transaction information is pushed to the manual verification platform, along with the intervention depth indicator, data structure difference indicator, and field integrity verification results corresponding to the current transaction;

[0130] After the manual intervention operation is completed, the transaction's automation credibility score is re-evaluated, and based on the new score, a decision is made whether to revert to the automated processing process or continue manual tracking and processing.

[0131] The transaction identification loss status means that the current transaction lacks a unified identification basis or has differences in high-risk fields, and it is impossible to ensure the consistency of its processing behavior among various business modules in the lifecycle management system.

[0132] Through the above steps, it is possible to timely mark and identify risky transactions with inconsistent identifiers or heterogeneous data structures when the automation credibility score is low, avoiding data mismatches, status drift, or duplicate entries when such transactions continue to enter the subsequent lifecycle processing links. The introduction of manual intervention processes provides a foundation for ensuring data consistency in subsequent links, improving the overall accuracy and reliability of cross-system collaborative processing. At the same time, it can accumulate samples of automated risky transactions, providing data support for subsequent model training and optimization of the system.

[0133] Embedding credibility assessment before the automated processing of transaction information can enhance the system's confidence in the results of automated processing. When low automation credibility is found at key steps, early intervention can be made to prevent errors from being transmitted to downstream systems. This will form a quantifiable automation quality indicator, namely the automation credibility score, which facilitates continuous system optimization and manual intervention decision-making.

[0134] Example 2: Please refer to Figure 2 As shown, the present invention is an over-the-counter derivatives lifecycle management system, including a transaction identification construction module, a data analysis and standardization module, a floating interest rate verification module, a unified transaction view module, an indicator calculation module, a credibility scoring module and a manual intervention trigger module;

[0135] A transaction identifier construction module, which constructs a unified transaction identifier for uniquely identifying an OTC derivative transaction based on predefined transaction fields. The unified transaction identifier uniquely identifies the same OTC derivative transaction flowing across systems;

[0136] The data parsing and standardization module performs structured parsing on 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, and nominal amount fields, and converts each field into a standard format based on predefined field semantic mapping rules.

[0137] The floating rate verification module builds a floating rate cash flow forecast model based on parsed standardized transaction confirmation data. By comparing the output of the floating rate cash flow forecast model with the counterparty's confirmation results, it achieves dual verification of the correctness of the floating rate formula and the consistency of the valuation. If the verification is inconsistent, the verification process is triggered;

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

[0139] The indicator calculation module calculates the depth of involvement index and data structure difference index of each business system involved in the comparison in the current transaction process. The depth of involvement index is used to measure the system's ability to directly generate or modify key fields, and the data structure difference index is used to evaluate the degree of heterogeneity in data formats, interface standards, and field granularity between systems.

[0140] a credibility scoring module that generates an automated credibility score based on the intervention depth indicator, data structure difference indicator, and field consistency comparison results, wherein the automated credibility score is used to quantify the reliability level of the automatic processing of the transaction at the current transaction stage;

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

[0142] This application designs an automated processing reliability verification mechanism to evaluate the reliability of automation capabilities before key processing steps in lifecycle management. The current transaction link is not a single operation link, but refers to any key step in the unified transaction identification generation and lifecycle processing process, such as transaction data parsing, transaction field standardization, cash flow forecast modeling, lifecycle event synchronization, etc. Before these steps are executed, the depth of involvement of each participating system in that step and the degree of data structure heterogeneity are dynamically evaluated, and combined with the consistency of field processing, an automation credibility score is generated.

[0143] Automated credibility scoring can proactively identify potential risks such as information disjointedness, structural discrepancies, and field parsing conflicts. A low score indicates that the automated processing in the current step is unreliable and has a high probability of failure or error. Therefore, manual intervention is necessary to prevent erroneous automated processing from causing data contamination or downstream disruption.

[0144] This application significantly enhances the stability, robustness and transparency of the cross-system lifecycle management mechanism driven by unified transaction identification, improves the quality of system processing, reduces the chain reaction of automation errors on downstream valuation, accounting and risk control systems, provides data basis for automation reliability assessment and manual intervention, and improves the compliance and reliability of the entire derivatives 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 the most recent real situation, and the preset parameters in the formulas are set by a person skilled in the art according to the actual situation.

[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. A method for managing the lifecycle of over-the-counter derivatives, characterized in that: The specific steps include: Based on predefined transaction fields, a unified transaction identifier is constructed for uniquely identifying OTC derivatives transactions. The unified transaction identifier uniquely identifies the same OTC derivatives transaction flowing across systems. Performs structured analysis on transaction confirmation data from various transaction source systems, identifies and extracts transaction fields, including frequency fields, floating rate calculation formula fields, and nominal amount fields, and converts each field into a standard format based on predefined field semantic mapping rules. Based on the parsed standardized transaction confirmation data, a floating rate cash flow forecast model is constructed. By comparing the output of the floating rate cash flow forecast model with the counterparty's confirmation results, a dual verification of the correctness of the floating rate formula and the consistency of the valuation is achieved. If the verification is inconsistent, the verification process is triggered; Based on unified transaction identification and standardized transaction confirmation data, a unified transaction view is constructed. When a lifecycle event is recorded in any business system, the event is synchronized to other business systems through the unified transaction view interface, achieving cross-system status synchronization and consistency maintenance of transaction lifecycle events. For each business system involved in the comparison, calculate its involvement depth index and data structure difference index in the current transaction link. The involvement depth index is used to measure the system's ability to directly generate or modify key fields, and the data structure difference index is used to assess the degree of heterogeneity in data formats, interface standards, and field granularity between systems. Based on the intervention depth indicator, data structure difference indicator and field consistency comparison results, an automation credibility score is generated, wherein the automation credibility score is used to quantify the reliability level of automatic processing of the transaction in the current transaction link; If the automation credibility score is lower than a 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 for managing the lifecycle of over-the-counter derivatives according to claim 1, characterized in that: Extracting fields required to form a transaction identifier from transaction confirmation data, transaction input data, or a transaction matching system, including at least one or more of the following: counterparty identifier, transaction effective date, maturity date, product type, notional amount, transaction currency, quote direction, and quote method; standardizing these fields, and performing a digest operation on the standardized field combination using a hash function to generate a unified transaction identifier; For transaction records that are highly similar but not completely duplicated, a configurable field weighted comparison mechanism is introduced to resolve conflicts and ensure the consistency of unified transaction identifiers. The generated unified transaction ID is written into the main transaction database as the primary key and mapped to the original transaction number. The unified transaction ID is synchronized to the valuation system, risk control system, and accounting system downstream modules through the interface to achieve cross-system consistent tracking. Based on the exception identification processing mechanism, when key fields are missing, the transaction is marked with the "Transaction Identification Abnormal" status, and the review and intervention process is triggered to prevent abnormal transaction identification from affecting downstream lifecycle processing.

3. The method for managing the lifecycle of over-the-counter derivatives according to claim 2, characterized in that: A configurable field weighted comparison mechanism is introduced to resolve conflicts in transaction records. The logic is as follows: The business system administrator presets a set of comparison fields, including: counterparty, transaction type, transaction start date, transaction end date, notional amount, floating rate definition, frequency, currency pair, transaction direction, and contract identifier. Each comparison field is assigned a corresponding weight value to indicate its influence in the overall similarity judgment. Among them, counterparty, transaction type, floating 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. For the two transactions to be compared, the aforementioned field values ​​are extracted for field similarity assessment. For text fields, the edit distance similarity is used; for numeric fields, the absolute difference and relative difference dual threshold similarity is used; and for date fields, the tolerable range similarity is used. After completing the field similarity evaluation, based on the preset field weights ,in is a set of preset field weights, is the weight of each field in the set, i is the field number, t is the total number of fields, and the similarity of each field is Perform weighted aggregation, where is the similarity set of each field, For field similarity, calculate the overall transaction similarity. The calculation expression is , where is the overall transaction similarity; Set the resolution threshold to Dith. If the calculated overall transaction similarity If the value is greater than or equal to the resolution threshold Dith, 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 calculated overall transaction similarity is If the difference is less than the resolution threshold Dith, the two transactions to be compared are determined to be independent transactions and are not merged. An exception identification processing mechanism is used to avoid abnormal problems.

4. The method for managing the lifecycle of over-the-counter derivatives according to claim 3, characterized in that: The method for using edit distance similarity evaluation for text fields is: For the texts of two transactions to be compared, the minimum number of operations required to make them completely consistent through insertion, deletion, or replacement is recorded as Ded. The similarity of the text fields is calculated based on the maximum length Lmax of the text. The calculation expression is: , where is the similarity of the text field, and the maximum text length Lmax is the longest of the two texts involved in the comparison. ,1 represents that the text fields of the two transactions are exactly the same; The method for evaluating similarity using dual thresholds of absolute difference and relative difference for numerical fields is: Calculate the absolute difference between the numerical fields of the two transactions to be compared. The absolute difference is ,in, is the absolute difference, and are the values ​​of the same numerical field of the two transactions to be compared. The preset absolute tolerance is Abto. The relative difference is calculated for the numerical fields of the two transactions to be compared. The relative difference is ,in, is the relative difference, the preset configuration threshold is Coth, then the similarity of the numerical fields of the two transactions to be compared is ,in, 1 indicates that the value fields of the two transactions are consistent. If it is 0, it means the value fields of the two transactions are inconsistent; The method for evaluating the similarity of the tolerable range for date fields is: Configure the maximum tolerated date offset Maxtdo and use the decay function to calculate the similarity of the date field. The calculation expression is: ,in, is the similarity of the date field, and are the values ​​of the same date field of the two transactions to be compared. The preset tolerance threshold is Toth. If If the date field of the two transactions is greater than or equal to the tolerance threshold Toth, it means that the date field of the two transactions is consistent. If it is less than the tolerance threshold Toth, it means that the date fields of the two transactions are inconsistent.

5. The method for managing the lifecycle of over-the-counter derivatives according to claim 1, characterized in that: After obtaining structured, standardized transaction confirmation data, a floating rate cash flow forecasting model is constructed based on standardized field content for OTC derivative transaction records involving floating rates. The floating rate cash flow forecasting model uses the value date, maturity date, notional amount, payment frequency, interest rate benchmark, interest rate spread, and reset frequency in the transaction confirmation data as input parameters, and combines real-time market data to calculate cash flow. Determine the start and end dates of each interest calculation period, calculate the applicable interest rate for the period based on the corresponding interest rate benchmark and the current floating rate formula, and generate the interest cash flow amount payable or receivable for each period. The cash flow sequence output by the floating rate cash flow forecasting model includes the start and end dates, receivable or payable direction, amount, and currency of each period; The model output results are compared with the confirmation results returned by the counterparty. If there are inconsistencies in the amount, inconsistencies in the interest calculation period, or obvious deviations in the calculation logic, it is determined that there is a deviation in the floating interest rate formula or inconsistent valuation logic, and the verification process is triggered. The transaction is marked as requiring review and pushed to the manual intervention process, where business personnel check the field identification, parameter calculation, and market data source.

6. The method for managing the lifecycle of over-the-counter derivatives according to claim 5, characterized in that: The unified transaction view uses a unified transaction identifier as an index to aggregate 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 manifestations of the same transaction throughout the entire process. The transaction confirmation information, valuation parameters, accounting attributes, settlement status, and lifecycle event content in each business system are normalized and structured to form a unified data object containing information on the entire transaction lifecycle. This unified data object can be queried and subscribed to through the unified transaction view interface. Obtain the status change data of the target transaction, which includes update records of transaction fields, operation instructions, timestamp information, and transaction unique identifier. Based on preset event recognition rules, perform matching analysis on the status change data to determine whether it meets the trigger conditions of a certain lifecycle event. If the preset conditions are met, extract the corresponding event type, construct a standardized event object, and push the constructed event object to the unified transaction view.

7. The method for managing the lifecycle of over-the-counter derivatives according to claim 1, characterized in that: The method to obtain the intervention depth index is: Based on the unified transaction view, the set of business systems involved in data processing in the current transaction link is identified and recorded as ,in, is the set of various business systems, p is the number of business systems, and the field set involved in the current transaction link is determined and recorded as ,in, 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 fields , analyze the control capability of the business system on the fields in the current transaction link. The control capability types include generation, modification, read-only and no access. Define the control value, where the control value Represents the business system Field Control value, control value The expression 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 The calculation expression is ,in, It is an indicator of the depth of involvement, used to indicate the control capability of the business system over the participating fields; The method to obtain the data structure difference index is: For each pair of business systems in the business system set participating in the current transaction link , collect its pairs of fields Data structure definition, including data type, interface encoding and field granularity, defines any field In the business system and The difference score between , the calculation expression is ,in, For data type differences, Encoding differences for interfaces, is the field granularity difference, and The data type differences are , interface coding differences and field granularity differences The proportionality coefficient of and All are positive numbers; Data type differences Used to evaluate whether the data types used in the same field in two business systems are consistent. If the field data types are exactly the same, then the data type difference The value is 1. If the field type is incompatible, the data type difference The value is 0; Interface encoding differences 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 , where Indicates the longest edit distance between two field name codes, which is the maximum value of the two field code lengths, and , interface encoding differences The larger the value, the greater the interface coding difference. The smaller the value, the smaller the interface coding difference; Field granularity differences Used to evaluate the difference in field expression granularity. The expression is ,in, is the number of subfields of the corresponding field h in the business system q, The number of subfields corresponding to field h in business system k, and the field granularity difference The larger the value, the greater the field splitting gap and the field granularity difference. The smaller it is, the smaller the field splitting gap is.

8. The method for managing the lifecycle of over-the-counter derivatives according to claim 7, characterized in that: For the indicator data generated by all the business systems involved in the current transaction, including the involvement depth indicator, data structure difference indicator and field integrity verification results, a linear weighted function is used to calculate the automated credibility score. , the calculation expression is , where and They are and The weight coefficient of and are all positive numbers, The integrity check result is The value is 0, otherwise, the integrity check result The value is 1; The preset trust threshold is Ceth. The calculated automation trust score Ats is compared with the trust threshold Ceth. If the calculated automation 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, and the warning transaction information is pushed to the manual verification platform, along with the intervention depth indicator, data structure difference indicator, and field integrity verification results corresponding to the current transaction; After the manual intervention operation is completed, the transaction's automation credibility score is re-evaluated, and based on the new score, a decision is made whether to revert to the automated processing process or continue manual tracking and processing.

9. An OTC derivatives lifecycle management system, used to implement the management method according to 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 indicator calculation module, a credibility scoring module, and a manual intervention trigger module; A transaction identifier construction module, which constructs a unified transaction identifier for uniquely identifying an OTC derivative transaction based on predefined transaction fields. The unified transaction identifier uniquely identifies the same OTC derivative transaction flowing across systems; The data parsing and standardization module performs structured parsing on transaction confirmation data from various transaction source systems, identifying and extracting transaction fields, including the frequency field, floating interest rate calculation formula field, and nominal amount field. Based on the predefined field semantic mapping rules, each field is converted into a standard format. The floating rate verification module builds a floating rate cash flow forecast model based on parsed standardized transaction confirmation data. By comparing the output of the floating rate cash flow forecast model with the counterparty's confirmation results, it achieves dual verification of the correctness of the floating rate formula and the consistency of the valuation. If the verification is inconsistent, the verification process is triggered; The unified transaction view module builds a unified transaction view based on unified transaction identification and standardized transaction confirmation data. When a lifecycle event is recorded in any business system, the event is synchronized to other business systems through the unified transaction view interface, achieving cross-system status synchronization and consistency maintenance of transaction lifecycle events. The indicator calculation module calculates the depth of involvement index and data structure difference index of each business system involved in the comparison in the current transaction process. The depth of involvement index is used to measure the system's ability to directly generate or modify key fields, and the data structure difference index is used to evaluate the degree of heterogeneity in data formats, interface standards, and field granularity between systems. a credibility scoring module that generates an automated credibility score based on the intervention depth indicator, data structure difference indicator, and field consistency comparison results, wherein the automated credibility score is used to quantify the reliability level of the automatic processing of the transaction at the current transaction stage; The manual intervention trigger module marks the transaction as a transaction identification loss state and triggers a manual intervention process when the automation credibility score is lower than a preset threshold, so as to avoid affecting the subsequent life cycle processing process.

Images