Systems and methods for computer-implemented financial reconciliation with automated discrepancy attribution via predicted snap timing analysis

Abstract

An example method for improving an efficiency and accuracy of a financial trade reconciliation platform (TRP) is provided. The method includes receiving, at the TRP and over a communications channel, a first and second valuation data for a financial instrument from first and second computing devices associated with first and second counterparties. The method includes determining, by a server-side processor of the TRP, a first and second predicted snap timings for the first and second valuation data. The method includes comparing the first and second predicted snap timings to detect a timing discrepancy between the first and second counterparties. The method includes generating, by the TRP, a digital dispute report indicating the timing discrepancy as a cause of a valuation discrepancy. The method includes sending, over the communications channel, the digital dispute report to the first and second computing devices for an automated resolution of the valuation discrepancy.

Description

Atty. Dockt. No.: 24-1235-WOSYSTEMS AND METHODS FOR COMPUTER-IMPLEMENTED FINANCIAL RECONCILIATION WITH AUTOMATED DISCREPANCY ATTRIBUTION VIA PREDICTED SNAP TIMING ANALYSISCROSS REFERENCE TO RELATED APPLICATIONS

[0001] This application claims priority to U.S. Provisional Application No.63 / 700,932 filed September 30, 2024, the contents of which are hereby incorporated by reference in their entirety.BACKGROUND

[0002] This application generally relates to portfolio reconciliation management, OTC derivatives, foreign exchange (FX) instruments, commodity forward contracts, power purchase agreements, cross-currency swaps, and dispute handling.SUMMARY

[0003] In the world of derivatives trading, portfolio reconciliation is a highly significant process where two parties verify that their records of trades, valuations, and other relevant details match. This ensures accuracy, mitigates risk, and helps participating firms comply with regulatory objectives. In this context, it can be challenging to identify mark-to-market valuation differences for FX contracts caused by two sides of a trade using different timings when capturing the spot rate used for valuing the contract.

[0004] Errors arising from using different FX timings can be both challenging to identify and cause large differences in valuations. It is generally believed that such errors are a significant reason for disputes about FX trades. For example, a commonly held belief among financial institutions and other participants in the portfolio reconciliation workflow is that FX timing-related differences may be playing a significant role in a majority of the disputes of uncleared trades. Collateral disputes that remain unresolved for a period of time may likely force some parties to set aside additional capital. These disputes generally have to be reported to regulators when they exceed a specific size and duration, resulting in unnecessary tied-up capital and increased administrative costs for banks and other participants in the Over-the-Counter (OTC) derivatives market. Also, for example, in a portfolio reconciliation service, a large proportion of FX contracts are flagged as potential valuation differences incorrectly due to the described issue, causing firms to have too many warnings for valuation issues, causing them to ignore the underlying valuation issue.1Atty. Dockt. No.: 24-1235-WO

[0005] Existing approaches do not provide a solution to this problem. Market participants may communicate individually on the resolution of differences on a small number of specific trades but the mark-to-market (MTM) valuation differences due to FX timing differences are in large parts ignored in the context of FX contracts. The term “mark-to-market” as used herein, generally feres to an accounting method used to value a financial instrument at its current market price. Clients resort to evaluating and comparing static trade data, but in reality, there may be other valuation issues not depending on the static data, such as, for example, market data issues. In situations where clients ask the counterparty to supply their snap time (if they have the possibility), current approaches involve manually comparing snap times of a small population of trades.

[0006] Accordingly, there is a need for an automatic system to detect errors arising from using different FX timings. Described herein is an approach that determines which timing a party to the trade uses, automatically quantifies the difference caused by using different timings, so that other types of valuation differences can be detected and not remain hidden (e.g., behind different spot rate timings).

[0007] The techniques described herein address a technical problem of valuation discrepancies in a financial trade reconciliation system. A trade reconciliation platform (e.g., OSTTRA™ TRIRESOLVE™) is a service that allows multiple parties to a transaction to compare their internal records. The primary goal is to identify and resolve discrepancies, ensuring that parties have a mutual understanding of the details associated with a trade. The underlying cause, an FX timing difference, is a technical issue related to data synchronization and valuation calculation within the computerized reconciliation system. The techniques described herein provide a technical solution by implementing a method on a trade reconciliation platform. The method uses a quantitative metric (e.g., predicted snap timing) to automatically detect a data discrepancy. This process improves the technical operation of the trade reconciliation system by making it more accurate and efficient in identifying the source of an error. The trade reconciliation platform's role as a centralized, trusted third party provides a technical framework for resolving the dispute automatically, which is a further technical advantage.

[0008] The trade reconciliation platform and its server-side processor can be configured to perform the operations. Operations involve receiving data from external computing devices, processing that data using calculations like determining predicted snap timings, and generating a digital report for automated resolution are technical steps that cannot be performed by a human mind. The solution involves technical steps that rely on computation to derive new information, such as the predicted snap timing and the timing discrepancy, from raw data. As2Atty. Dockt. No.: 24-1235-WOdescribed herein, the technology improves the functioning of the reconciliation system itself. The dispute resolution is an automated process that increases the efficiency and accuracy of the reconciliation system by identifying a specific, quantifiable technical issue (e.g., timing discrepancy). It directly addresses the technical problem of disparate valuation data, which is an output of a computer system.

[0009] These solutions described herein are scalable to identify FX snap timings on a large population of trades and can have an effect on both the portfolio reconciliation process, the dispute management process and can decrease the number of disputes in the market. The described system may automatically, in the case of an FX timing difference, flag a trade for snap timing difference. This results in fewer trades that are to be manually investigated for valuation differences by the portfolio reconciliation teams of the market participants. The system may be configured to flag trades that are not valued in relation to reported trade economics and market movements which are trades with high risk of booking issues or other issues. The techniques described herein decrease the complexity of the dispute management process and the corresponding margin process enabling swifter resolutions of disputes when they arise due to FX snap timing differences. These techniques make it possible to highlight, on a portfolio level, which of a market participant’s counterparty have large number of trades with snap timing differences, making it possible to focus the effort to resolve differences in snap timing in relation to the counterparty. This has the effect of decreasing the number of disputes and decreasing the overall risk in the financial market.

[0010] In a first aspect, a computer-implemented method for improving an efficiency and accuracy of a financial trade reconciliation platform is provided. The method includes receiving, at the trade reconciliation platform and over a communications channel, a first valuation data for a financial instrument from a first computing device associated with a first counterparty, and second valuation data for the financial instrument from a second computing device associated with a second counterparty. The method also includes determining, by a server-side processor of the trade reconciliation platform, a first predicted snap timing for the first valuation data and a second predicted snap timing for the second valuation data. The method further includes comparing, by the server-side processor, the first predicted snap timing to the second predicted snap timing to detect a timing discrepancy between the first and second counterparties. The method also includes generating, by the trade reconciliation platform, a digital dispute report indicating the timing discrepancy as a cause of a valuation discrepancy. The method further includes sending, over the communications channel, the digital dispute3Atty. Dockt. No.: 24-1235-WOreport to the first and second computing devices for an automated resolution of the valuation discrepancy.

[0011] In a second aspect, a computing device for improving an efficiency and accuracy of a financial trade reconciliation platform is provided. The computing device includes one or more processors, and data storage, wherein the data storage has stored thereon computer-executable instructions that, when executed by the one or more processors, cause the computing device to carry out operations. The operations include receiving, at the trade reconciliation platform and over a communications channel, a first valuation data for a financial instrument from a first computing device associated with a first counterparty, and second valuation data for the financial instrument from a second computing device associated with a second counterparty. The operations further include determining, by a server-side processor of the trade reconciliation platform, a first predicted snap timing for the first valuation data and a second predicted snap timing for the second valuation data. The operations also include comparing, by the server-side processor, the first predicted snap timing to the second predicted snap timing to detect a timing discrepancy between the first and second counterparties. The operations further include generating, by the trade reconciliation platform, a digital dispute report indicating the timing discrepancy as a cause of a valuation discrepancy. The operations additionally include sending, over the communications channel, the digital dispute report to the first and second computing devices for an automated resolution of the valuation discrepancy.

[0012] In a third aspect, a computer program for improving an efficiency and accuracy of a financial trade reconciliation platform is provided. The computer program comprises instructions that, when executed by a computer, cause the computer to perform operations. The operations include receiving, at the trade reconciliation platform and over a communications channel, a first valuation data for a financial instrument from a first computing device associated with a first counterparty, and second valuation data for the financial instrument from a second computing device associated with a second counterparty. The operations further include determining, by a server-side processor of the trade reconciliation platform, a first predicted snap timing for the first valuation data and a second predicted snap timing for the second valuation data. The operations also include comparing, by the server-side processor, the first predicted snap timing to the second predicted snap timing to detect a timing discrepancy between the first and second counterparties. The operations further include generating, by the trade reconciliation platform, a digital dispute report indicating the timing discrepancy as a cause of a valuation discrepancy. The operations additionally include sending, over the4Atty. Dockt. No.: 24-1235-WOcommunications channel, the digital dispute report to the first and second computing devices for an automated resolution of the valuation discrepancy.

[0013] In a fourth aspect, an article of manufacture for improving an efficiency and accuracy of a financial trade reconciliation platform is provided. The article of manufacture may include a non-transitory computer-readable medium comprising program instructions executable by one or more processors to cause the one or more processors to perform operations. The operations include receiving, at the trade reconciliation platform and over a communications channel, a first valuation data for a financial instrument from a first computing device associated with a first counterparty, and second valuation data for the financial instrument from a second computing device associated with a second counterparty. The operations further include determining, by a server-side processor of the trade reconciliation platform, a first predicted snap timing for the first valuation data and a second predicted snap timing for the second valuation data. The operations also include comparing, by the server-side processor, the first predicted snap timing to the second predicted snap timing to detect a timing discrepancy between the first and second counterparties. The operations further include generating, by the trade reconciliation platform, a digital dispute report indicating the timing discrepancy as a cause of a valuation discrepancy. The operations additionally include sending, over the communications channel, the digital dispute report to the first and second computing devices for an automated resolution of the valuation discrepancy.

[0014] In a fifth aspect, a system for improving an efficiency and accuracy of a financial trade reconciliation platform is provided. The system includes means for receiving, at the trade reconciliation platform and over a communications channel, a first valuation data for a financial instrument from a first computing device associated with a first counterparty, and second valuation data for the financial instrument from a second computing device associated with a second counterparty; means for determining, by a server-side processor of the trade reconciliation platform, a first predicted snap timing for the first valuation data and a second predicted snap timing for the second valuation data; means for comparing, by the server-side processor, the first predicted snap timing to the second predicted snap timing to detect a timing discrepancy between the first and second counterparties; means for generating, by the trade reconciliation platform, a digital dispute report indicating the timing discrepancy as a cause of a valuation discrepancy; means for sending, over the communications channel, the digital dispute report to the first and second computing devices for an automated resolution of the valuation discrepancy.5Atty. Dockt. No.: 24-1235-WO

[0015] The foregoing summary is illustrative only and is not intended to be in any way limiting. In addition to the illustrative aspects, embodiments, and features described above, further aspects, embodiments, and features will become apparent by reference to the figures and the following detailed description and the accompanying drawings.BRIEF DESCRIPTION OF THE FIGURES

[0016] FIG. 1 illustrates an example reconciliation process without foreign exchange (FX) timing prediction, in accordance with example embodiments.

[0017] FIG.2 illustrates an example FX timing prediction process flow, in accordance with example embodiments.

[0018] FIG.3 illustrates an example timing dispute attribution, in accordance with example embodiments.

[0019] FIG. 4 illustrates an example reconciliation process with FX timing prediction, in accordance with example embodiments.

[0020] FIG.5 is an example graphical illustration of an intra-day spot trade, in accordance with example embodiments.

[0021] FIG. 6A is an example illustration of determining a distance, in accordance with example embodiments.

[0022] FIG.6B is an example distribution of a number of trades based on a distance per trade, in accordance with example embodiments.

[0023] FIG. 7 is an example distribution of a collection of trades based on predicted snap timings for each side of the trade, in accordance with example embodiments.

[0024] FIG. 8 is an example graphical illustration of a distance in mark-to-market (MTM) valuations, in accordance with example embodiments.

[0025] FIG. 9 depicts a distributed computing environment, in accordance with example embodiments.

[0026] FIG.10 is a block diagram illustrating an example computer device, in accordance with example embodiments.

[0027] FIG. 11 is a flowchart of an example method, in accordance with example embodiments.6Atty. Dockt. No.: 24-1235-WODETAILED DESCRIPTION

[0028] This application generally relates to portfolio reconciliation management, OTC derivatives, foreign exchange (FX) instruments, commodity forward contracts, power purchase agreements, cross-currency swaps, and dispute handling.

[0029] In the current portfolio reconciliation process, trade data undergoes normalization, matching, and preprocessing before being rigorously tested to identify a dispute attribution. Through a sequence of methodical tests, a trade is assigned a specific dispute attribution. If no significant discrepancies are found in relevant economic fields but a difference remains, the trade may be categorized under "FX timing" as its dispute attribution. Notably, for FX trades, the majority are classified with "FX timing" as their dispute attribution.

[0030] FIG.1 illustrates an example reconciliation process without FX timing prediction 100, in accordance with example embodiments. For example, FIG.1 outlines an existing process for portfolio reconciliation, focusing on how a trade is categorized by a relevant dispute attribution. The flowchart is a sequential process that evaluates a trade against different potential errors to assign a dispute category.

[0031] In some embodiments, the process begins with two parallel inputs: Party A's trade data is received at block 105 and Party B's trade data is received at block 110. Block 115 involves normalizing and matching these data sets against the counterparty. At block 120, the system may be configured to run tests and diagnostics to detect relevant differences, such as missing fields, incorrect currency, or mapping errors.

[0032] The process then enters a series of decision steps, represented by the dashed box. Block 125 is configured to determine whether the trade has a population type issue (related to matching). Upon a determination that the trade has a population type issue, the process moves to block 130 where a match error is set as the dispute attribution. Upon a determination that the trade does not have a population type issue, the process moves to block 135.

[0033] Block 135 is configured to determine whether the trade has a valuation error type issue (e.g., stale MTM (valuation not moving over time) or zero MTM (MTM value is 0)). Upon a determination that the trade has a valuation error type issue, the process moves to block 140 where a valuation error is set as the dispute attribution. Upon a determination that the trade does not have a valuation error type issue, the process moves to block 145.

[0034] Block 145 is configured to determine whether the trade is of a product class eligible for FX timing difference, and no relevant differences have been detected. Upon a determination that the trade is of a product class eligible for FX timing difference, and no relevant differences7Atty. Dockt. No.: 24-1235-WOhave been detected, the process moves to block 150 where FX timing is set as the dispute attribution. Upon a negative determination at block 145, the process moves to block 155.

[0035] Block 155 is configured to determine whether the trade has other valuation issues. Upon a determination that the trade has other valuation issues, the process moves to block 160 where the valuation issues are set as the dispute attribution. Upon a determination that the trade does not have other valuation issues, the process moves to block 165 where a persistent difference is set as the dispute attribution.

[0036] The technologies described herein aim to enhance the analysis of FX timing dispute attribution by identifying and classifying the specific snap timing used by the counterparties. This information may be communicated to both sides of the trade. Beyond enabling synchronization of timing between parties, this advancement may also help isolate and identify other sources of errors in the reconciliation workflow that are currently undetectable.

[0037] In practice, this enhancement may be integrated as an additional task within block 120 of the portfolio reconciliation process of FIG. 1. Here, a snap timing prediction ^^^^ and a corresponding distance ^^^^ may be determined and recorded alongside other relevant calculations. The procedure for deriving these metrics is further described herein.

[0038] The technologies described herein relate to a computer-implemented solution to a problem within the financial trade reconciliation system. A “financial trade reconciliation system” can be a system used by parties to verify that their records of trades, valuations, and other relevant details match. In some embodiments, this may be an industry-standard portfolio reconciliation service (e.g., OSTTRA™ TRIRESOLVE™) that streamlines this process. The process may be performed on a valuation platform, which is a central system that provides a shared view of portfolio data to increase transparency and fosters trust between counterparties. This approach is a scalable method to identify FX snap timings on a large population of trades and is expected to decrease the number of disputes in the market.

[0039] Some features and services of OSTTRA™ TRIRESOLVE™ include centralized Data Submission where users upload their portfolio data to a secure platform, and standardized data mapping that normalizes the data using a common set of definitions, ensuring substantial consistency between counterparties. The platform employs a sophisticated algorithmic match engine to automatically compare portfolios and identify discrepancies enabling automated reconciliation. The platform also provides a comprehensive workflow for investigating and resolving breaks, including commenting, document sharing, and collaboration features, thereby enabling efficient break resolution.8Atty. Dockt. No.: 24-1235-WO

[0040] Some of the significant benefits of the platform include a reduction of operational risk. This is achieved by automation that minimizes manual errors and streamlines the reconciliation process. Faster reconciliation cycles and reduced manual intervention save time and resources thereby enhancing efficiency. The platform helps firms meet regulatory obligations for portfolio reconciliation and risk management, thereby facilitating regulatory compliance. A shared view of portfolio data increases transparency and fosters trust between counterparties. Being part of the TRIRESOLVE™ network allows firms to connect with a vast number of counterparties for efficient reconciliation.

[0041] Some embodiments involve receiving, at the trade reconciliation platform and over a communications channel, a first valuation data for a financial instrument from a first computing device associated with a first counterparty, and second valuation data for the financial instrument from a second computing device associated with a second counterparty. For example, the process may begin with receiving trade data from two parties, Party A and Party B. This data, including valuations and notionals, may be uploaded to a secure platform. The data may be transferred over a communications channel or network. The counterparties may use various computing devices like desktops, tablets, or smartphones to upload the data.

[0042] The term “communications channel” generally refers to a medium or path for transmitting data between different computing devices, such as a network. The term “valuation data” generally refers to information used to determine the value of a financial instrument, including mark-to-market (MTM) valuations and notional amounts. A “financial instrument” can be a contract or asset that can be traded, such as an FX forward. An FX (Foreign Exchange) Forward is a customized contract between two parties to exchange a specified amount of one currency for another at a pre-agreed exchange rate (the forward rate) on a future date (the maturity date).

[0043] Unlike standardized futures contracts, FX forwards are traded directly between parties (often a bank and its client) and can be tailored to specific objectives. In some embodiments, the first counterparty may be a bank, and the second counterparty may be a client. The parties can negotiate the amount of currency, the exchange rate, and the maturity date to suit their individual objectives. Both parties are legally obligated to complete the transaction at the agreed-upon rate and date, regardless of market fluctuations. FX forwards are primarily used to hedge against currency risk. If a business expects to receive or pay an amount in a foreign currency in the future, they can lock in a favorable exchange rate with a forward contract, protecting themselves from adverse currency movements. While less common, FX forwards can also be used for speculation on future currency movements.9Atty. Dockt. No.: 24-1235-WO

[0044] FX forwards generally involve an agreement where two parties agree on the amount of currency to exchange, the exchange rate, and the future date for the exchange. FX forwards also involve a legally binding contract specifying the terms of the agreement. On the maturity date, the parties exchange the currencies at the pre-agreed rate.

[0045] For example, a U.S. company may expect to receive €1 million from a European client in six months. Worried that the euro might weaken against the dollar, the company may enter into an FX forward contract with a bank to exchange the euros for dollars at a pre-agreed rate on the date of receipt. This locks in the exchange rate, protecting the company's profits from potential euro depreciation. Some factors that may impact forward rates include a spot exchange rate (e.g., a current exchange rate between the two currencies), an interest rate differential (e.g., a difference in interest rates between the two countries), a time to maturity (e.g., a length of time until the currencies are exchanged), and market expectations (e.g., forecasts of future exchange rate movements can also influence forward rates).

[0046] The term “client” is a broad term that can refer to any individual or entity that uses the services of a professional person or organization. For example, this may be common for OTC financial instruments like FX forwards, which are traded directly between parties. These contracts can be customized to suit the specific objectives of the bank and its client.

[0047] In some embodiments, the first and second counterparties may be financial institutions. A financial institution may be a bank, insurance company, or investment firm. Portfolio reconciliation is a significant process where two parties verify their records to ensure accuracy and mitigate risk. Financial institutions often use a service like OSTTRA™, which facilitates reconciliation for a vast number of counterparties. Being part of this network allows firms to connect with a large number of other financial institutions for efficient reconciliation.

[0048] In some embodiments, the first counterparty may be a financial institution, and the second counterparty may be a corporation. This may be a common arrangement in derivatives trading, particularly for customized OTC financial instruments. For example, a corporation may enter into a derivatives contract with a financial institution, such as a bank, to manage financial risks. For example, a U.S. company may enter an FX forward contract with a bank to lock in an exchange rate for a future payment, protecting its profits from potential currency depreciation.

[0049] In some embodiments, the first and second valuation data may include a series of daily mark-to-market (MTM) valuation reports for an over-the-counter (OTC) financial instrument. For example, the method relies on valuation data that is updated and reported on a daily basis for financial instruments traded directly between two parties. MTM is a method of valuing10Atty. Dockt. No.: 24-1235-WOfinancial positions at the current market price. The techniques described herein use a series of these reports to analyze the day-to-day changes in a trade value. These MTM reports are significant because they capture the value fluctuations of the financial instrument, which can be linked to the movement of the underlying spot rate. By using a series of daily reports, the system can create a vector of these daily changes to compare against the spot rate vectors.

[0050] OTC financial instruments are customized contracts traded directly between two parties. The process described herein is particularly beneficial for instruments whose valuation depends on fluctuating prices or exchange rates throughout the day. Examples include FX forwards and other FX instruments, commodity forwards (e.g., oil and gold), cross-currency swaps, and power purchase agreements. Unlike standardized futures contracts, OTC instruments can be tailored to specific objectives and are not subject to the same centralized reporting and standardization, making reconciliation a more complex process.

[0051] FX forwards and other FX instruments may be used to manage currency risk and facilitate foreign exchange transactions. An FX forward is a customized OTC contract between two parties to exchange a specified amount of one currency for another at a pre-agreed exchange rate on a future date. Unlike standardized futures contracts, FX forwards are traded directly between parties and can be tailored to specific objectives, including the amount, exchange rate, and maturity date. Both parties are legally obliged to complete the transaction at the agreed-upon rate, regardless of market fluctuations. FX forwards are primarily used as a hedging tool to protect against currency risk. For instance, a company expecting to receive foreign currency in the future can use a forward contract to lock in a favorable exchange rate, protecting its profits from adverse currency movements. While less common, they can also be used for speculation on future currency movements. The forward rate may be influenced by several factors, including the current spot exchange rate, interest rate differentials between the two countries, and the time to maturity. The techniques described herein for analyzing FX timing differences may also be applicable to other FX instruments, not just forwards. The valuation of these instruments, like forwards, depends on prices or exchange rates that fluctuate throughout the day.

[0052] A commodity forward is a customized contract between two parties to exchange a specified amount of a commodity for another at a pre-agreed price on a future date. They are a type of OTC derivative, and their valuation depends on fluctuating prices throughout the day. The techniques described herein for analyzing FX timing differences can also be applied to commodity forwards, such as those for oil or gold.11Atty. Dockt. No.: 24-1235-WO

[0053] A Power Purchase Agreement (PPA) is a customized contract between two parties to exchange a specified amount of electricity at a pre-agreed price on a future date. Because electricity prices can vary throughout the day, the valuation of a PPA depends on fluctuating prices, making it a suitable candidate for the reconciliation method described in the appendix. PPAs are a type of OTC derivative.

[0054] A cross-currency swap is a financial contract between two parties who agree to exchange an equivalent amount of principal in different currencies. These swaps are typically used by financial institutions and multinational corporations to manage various financial exposures. A cross-currency swap may involve an initial exchange where, at the beginning of the contract, the two parties exchange the notional principal amounts in two different currencies. This exchange is typically made at the prevailing spot exchange rate. The cross-currency swap may also involve periodic interest payments. For example, throughout the life of the swap, a party makes regular interest payments on the currency they received. The interest rates can be either fixed or floating, and the payment schedule is customized to meet the objectives of the counterparties. Finally, at the contract's maturity, the initial principal amounts are swapped back at the same exchange rate as the initial exchange. This final step ensures that both parties return to their original currency positions and eliminates principal currency risk.

[0055] Cross-currency swaps are highly flexible, OTC products that can be customized for specific objectives. They may be used for hedging currency risk (e.g., to protect against unfavorable foreign exchange rate fluctuations), accessing foreign capital markets (e.g., borrow at a cheaper rate in its home currency and then use a swap to acquire the target foreign currency, aligning the debt servicing with the revenue currency), optimizing funding costs (e.g., swapping currencies at more favorable interest rates to reduce borrowing expenses and enhance a financial position), and / or to manage interest rate risk (e.g., swap allows parties to choose between fixed or floating interest rates, which helps them adjust their interest rate exposure).

[0056] In some embodiments, the first and second valuation data may include mark-to-market (MTM) values and notional amounts. The MTM value is a valuation of a contract based on current market prices. The notional amount may be the specified quantity of a currency for a side of the trade. The MTM valuation for an FX Forward, for example, may be calculated using the notional amounts for a currency, discount factors for a currency of the financial instrument, and the spot exchange rate. Both MTM values and notional amounts may be shown in the currency agreed upon in the contract. The daily changes in these values can be used to calculate the normalized percentage differences that form the basis of the valuation vector in the method described herein.12Atty. Dockt. No.: 24-1235-WO

[0057] Some embodiments involve determining, by a server-side processor of the trade reconciliation platform, a first predicted snap timing for the first valuation data and a second predicted snap timing for the second valuation data. For example, an optimal distance and associated snap time prediction may be determined. This may be performed by a server-side processor, which computes a distance between a party's valuation data and a range of spot rate data for a currency pair. In some embodiments, the lowest distance may correspond to the predicted snap timing for a party. A “server-side processor” may generally refer to a processor within a centralized system (like the trade reconciliation platform) that performs the data processing and calculations.

[0058] In some embodiments, the determining of the first and second predicted snap timings involves determining a valuation vector by normalizing a daily change in the received valuation data for the first and second counterparties. For example, a valuation vector (^^^^) may be determined for a party. This vector captures the day-to-day changes in the trade's value. The daily change may be normalized by dividing the difference in the mark-to-market (MTM) value by the previous day's value plus the notional amount. Such a normalization helps account for the scale of the trade.

[0059] In some embodiments, the determining of the first and second predicted snap timings may be based on a comparison of a normalized daily percentage change of the valuation data and a daily percentage change of spot exchange rates. For example, a series of day-to-day percentual differences may be determined for the valuation of the trade. Such a valuation vector may then be compared against a set of vectors representing the daily percentage changes of the spot rate for possible snap timings. Since the delta of an FX forward is close to 1, a percentage change in the spot rate is likely to lead to a similar percentage change in the valuation of the trade. The process described herein identifies the snap timing that satisfies this relationship. In some embodiments, the closest match, measured by an appropriate metric, can be taken as the predicted snap timing for that valuation. Although selecting a maximum value may be the optimal solution in some cases, other measures of optimal may be used. In some embodiments, a correlation coefficient may be optimized.

[0060] Some embodiments involve calibrating a threshold using test data to be used as an error margin. For example, determining the accuracy of the snap timing prediction may be based on calibrating the threshold using test data. Some embodiments involve executing a prediction accuracy test by determining if a normalized optimal distance for both the first and second valuation data is below the calibrated threshold. For example, the system may determine if a normalized optimal distance for a trade is below the calibrated threshold. In some13Atty. Dockt. No.: 24-1235-WOembodiments, the normalized optimal distance may be calculated by dividing the optimal Euclidean distance (^^^^) by the number of days (^^^^) used in the calculation.

[0061] The threshold may not be a fixed value; it can be calibrated by comparing a large number of trades across various party relationships and currency pairs against validation data. A lower threshold ensures higher precision in the predictions, but it means fewer trades are likely to meet the criteria. The more days of data used for the comparison, the more accurate the prediction, and the threshold may be adjusted accordingly.

[0062] In some embodiments, if the prediction accuracy test fails for at least one of the first or second valuation data, the digital dispute report may be generated to indicate a different underlying error, wherein the different underlying error include a match error, or an incorrect booking of payment direction or currency. For example, if the prediction accuracy test fails for valuation data associated with at least one party, a digital dispute report may be generated to indicate an underlying error other than FX timing. A failed test can mean that the minimal distance is not below the calibrated threshold, suggesting the valuation movements for the trade do not correspond well with any of the spot rate movements. This can be a sign of a high-risk trade with other issues.

[0063] Some underlying errors may include a match error (e.g., may occur when a trade from one party does not correctly match the same contract from the other party), or incorrect booking (e.g., errors in reporting trade economics, such as a wrong notional amount, incorrect payment direction, or wrong currency).

[0064] Such embodiments also involve receiving a reference data set of spot rates and calculating a matrix of spot rate vectors, wherein a spot rate vector represents a daily percentage change in a spot rate for a specific time of day. For example, the system may generate a matrix (^^^^) of spot rate vectors. This matrix can represent a series of day-to-day percentage changes for the underlying spot rate, with a separate vector for a possible time of day the rate could have been captured. For example, using a five-minute time interval can result in about 288 possible snap timings per day.

[0065] Such embodiments further involve determining a vector of distances by comparing the valuation vector to spot rate vectors. For example, the system may calculate a vector of distances (^^^^) by comparing the valuation vector (^^^^) to the spot rate vectors in the matrix (^^^^). The distance quantifies how closely the valuation's daily movements match the movements of the spot rate at a specific time of day. A smaller distance indicates a better match.14Atty. Dockt. No.: 24-1235-WO

[0066] In some embodiments, the vector of distances may be based on one of a Euclidean distance, a Manhattan distance, a cosine similarity, a correlation coefficient, or a Dynamic Time Warping (DTW) algorithm. The vector of distances is a set of values that measure the similarity or dissimilarity between a trade's valuation movements and the movements of the underlying spot exchange rate at various times throughout the day. This vector is used to find a probable "snap timing" for a trade's valuation.

[0067] The Euclidean distance may be used as a measure of distance, calculated as the square root of the sum of the squared differences between corresponding points in two vectors. It is highly sensitive to large differences and finds the geometric distance between two points in Euclidean space.

[0068] The Manhattan distance, also known as the L1 norm, sums the absolute differences between the coordinates of two vectors. Unlike Euclidean distance, it may be less influenced by outliers because it doesn't square the differences.

[0069] A cosine similarity determines the cosine of the angle between two vectors. It is useful for determining if two vectors are pointing in the same direction, regardless of their magnitude. This means it would focus on the pattern of daily changes in addition to, or instead of, a size of those changes

[0070] A correlation coefficient is a statistical measure that quantifies a linear relationship between two variables. A high correlation coefficient (close to 1 or -1) would indicate that the daily movements of the trade's valuation are strongly and consistently related to the movements of the spot rate at a specific time.

[0071] DTW is an algorithm that is used to measure the similarity between two temporal sequences that may vary in speed. For example, if a party's snap timing is not substantially consistent on a daily basis and fluctuates by a few minutes, DTW could still find a strong match by "warping" one sequence to align with the other.

[0072] In some embodiments, the predicted snap timing may be determined by fitting a linear function to the delta valuations with respect to delta spot rates. Various techniques for fitting a linear model to a set of data points, particularly in the presence of noise or outliers, may be used. Such techniques may include a linear regression, a Random Sample Consensus (RANSAC), a Huber method, or a Theil-Sen estimator. When the linear function has been determined. various metrics may be used to find the predicted snap timing. Such metrics may include, but are not limited to, MAE (Mean Absolute Error) and RMSE (Root Mean Squared Error). For example, MAE and RMSE may be used to measure the accuracy of a model's15Atty. Dockt. No.: 24-1235-WOpredictions. Both calculate the average error, but in different ways, which can make one more suitable than the other depending on the situation.

[0073] MAE involves determining an average of the absolute differences between the predicted and actual values. For example, MAE may be calculated by taking the sum of the absolute errors and dividing it by the number of data points. Some advantages of MAE are simplicity and interpretability. Because it uses absolute values, MAE directly measures the average magnitude of the errors without considering their direction. This means that errors contribute proportionally to the total error, making it easy to understand and explain. RMSE is the square root of the average of the squared differences between the predicted and actual values. For example, RMSE may be calculated by squaring the difference for data points, finding the average of these squared errors, and then taking the square root.

[0074] One difference between RMSE and MAE is the squaring of the errors. Because the errors are squared before they are averaged, RMSE gives more weight to larger errors. This means that a model with a few large errors may have a significantly higher RMSE than a model with many small errors, even if the MAE is the same for both. This property makes RMSE particularly useful when large errors are undesirable, as it penalizes them more heavily.

[0075] A linear regression is a statistical method that models the relationship between two variables by fitting a straight line to the data points. This involves finding the line that minimizes the sum of the squared vertical distances between data points and the line itself. This approach, also known as the Ordinary Least Squares (OLS) method, is effective but can be highly sensitive to outliers. A single outlier may significantly skew the slope and intercept of the resulting line.

[0076] RANSAC is an iterative algorithm used to estimate the parameters of a mathematical model from a set of observed data that contains a significant number of outliers. Unlike linear regression, which uses the data points, RANSAC randomly selects a small subset of "inliers" from the data and uses them to fit an initial model. It then checks how many of the other data points are substantially consistent with this model (i.e., are within a threshold distance of the line). The algorithm repeats this process for a number of iterations, keeping the model that covers an appropriate number of inliers. The final model may be refined using the inliers found. This makes RANSAC robust to outliers, as it can successfully find a good fit even when a majority of the data is noisy.

[0077] The Huber method is a robust regression technique that behaves like linear regression for data points that are close to the fitted line (inliers) and like least absolute deviation regression for data points that are far from the line (outliers). Instead of squaring the error for16Atty. Dockt. No.: 24-1235-WOthe data points, Huber uses a squared error for small residuals and a linear error for large residuals. This means it does not heavily penalize large errors from outliers, making it more resilient to them than linear regression.

[0078] The Theil-Sen estimator, also referred to as Sen's slope estimator, is a non-parametric method for estimating the slope of a line that is robust to outliers. This approach involves calculating the slope for pairs of data points and then taking the median of these slopes. This median slope is a much more stable estimate than the slope from linear regression because it is not affected by a few extreme data points. Theil-Sen is particularly useful for data with a lot of noise or when the underlying relationship is not substantially linear.

[0079] Such embodiments also involve identifying the first and second predicted snap timings by determining a time of day corresponding to a minimum value in the vector of distances. For example, the system may identify the predicted snap timing for a party by finding the minimum value in the vector of distances (^^^^). The time of day that corresponds to this minimal distance is the predicted snap timing, as it represents the spot rate data that explains the movement of the trade's valuation. This process is performed for a party's valuation data to get their respective snap timing predictions.

[0080] Some embodiments involve comparing, by the server-side processor, the first predicted snap timing to the second predicted snap timing to detect a timing discrepancy between the counterparties. For example, after determining the snap timings for both parties, the method may check whether the predicted timings are the same for both parties.

[0081] The term “predicted snap timing” as used herein, generally refers to a probable time of day a party used to capture the spot exchange rate for a valuation, identified by finding the minimum distance between the valuation data and the spot rate data. The term “timing discrepancy” generally refers to a difference in the predicted snap timings used by two counterparties for the same trade, which can cause valuation differences.

[0082] Some embodiments involve generating, by the trade reconciliation platform, a digital dispute report indicating the timing discrepancy as a cause of a valuation discrepancy. For example, if the snap timings are not the same, the trade may be labeled with an FX timing as a Dispute Attribute. The new process enhances this by setting a Dispute Attribution for FX timing using Snap timing prediction. This report provides specific details about the timing difference, which can be a significant factor in resolving the dispute.

[0083] The term “digital dispute report” generally refers to a digital document or message generated by the system to flag a specific issue, such as a valuation or FX timing error, for resolution. An “automated resolution” generally refers to a process of resolving a dispute17Atty. Dockt. No.: 24-1235-WOwithout manual intervention; by providing the counterparties with the specific cause of the discrepancy so they can correct it.

[0084] Some embodiments involve sending, over the communications channel, the digital dispute report to the first and second computing devices for an automated resolution of the dispute. For example, the dispute report may be communicated to both sides of the trade to enable synchronization of their timing. This allows for swifter resolutions of disputes and helps to decrease the overall risk in the financial market. This transmission may occur over a network.

[0085] In some embodiments, the automated resolution involves providing the predicted snap timings to the first and second counterparties to enable synchronization of their timing. For example, the proposed solution enhances the existing portfolio reconciliation process by identifying and classifying the specific snap timing used by a party. Once the system determines that the snap timings are different, causing a valuation discrepancy, it communicates this information to both sides of the trade. By providing the specific predicted snap timings, the counterparties can understand the precise reason for the valuation difference and adjust their processes to use a substantially consistent timing going forward. This allows for a swift resolution of disputes and helps to prevent future discrepancies, and results in reducing the number of disputes in the market and lowering administrative costs for financial institutions.

[0086] In some embodiments, the digital dispute report further includes a quantified size of an error caused by the timing discrepancy. For example, the digital dispute report may go beyond simply flagging a timing discrepancy. The digital dispute report may also provide a quantified size of the error caused by this difference in snap timings. This is a significant enhancement to the existing portfolio reconciliation process, which fails to provide additional details about the cause or magnitude of the issue.

[0087] The quantified size of the error may be determined as a difference in the MTM valuations that result from the two parties using different snap timings. For example, if Party A valuation is -$5,545,625 USD and Party B valuation is +$5,940,625 USD, the valuation difference may be determined as an absolute sum of their MTM values, resulting in an error of $395,000 USD. Also, for example, the techniques described herein may distinguish how much of the $395,000 USD is caused by snap timing and how much of it is caused by other factors such as market data differences or some other error. In many situations, it is unlikely that 100% of the MTM difference can be attributed to currency differences. Accordingly, an ability to quantify and separate FX timing-related MTM differences is a significant factor. By including such information, the digital dispute report gives both parties a clear understanding of the18Atty. Dockt. No.: 24-1235-WOfinancial impact of their timing difference. This makes it easier for the parties to resolve the dispute and decide on a course of action. It also helps them identify the remaining valuation difference that could be caused by other factors, such as different discount factors.

[0088] In some embodiments, the trade reconciliation platform may be a component of a portfolio reconciliation service. For example, OSTTRA™ is a leading portfolio reconciliation service, and has become the de facto industry-standard for this purpose. OSTTRA™ provides a centralized, standardized, and automated platform for portfolio reconciliation, which has revolutionized how firms manage their derivatives portfolios. The platform facilitates the reconciliation of over 90% of bilateral OTC derivatives globally. The platform's ability to identify and resolve disputes, including FX timing errors, makes it a significant component for ensuring accuracy, mitigating risk, and helping firms comply with regulatory objectives.

[0089] FIG.2 illustrates an example foreign exchange (FX) timing prediction process flow 200, in accordance with example embodiments. For example, FIG.2 illustrates a process for predicting snap timing and distance for an FX trade to identify if a valuation difference is caused by an FX timing issue. Block 205 involves receiving market-to-market (MTM) valuations and notional amounts. Block 210 involves receiving foreign exchange (FX) data for a specific currency pair. After receiving these inputs, the process continues with two parallel determinations.

[0090] At block 215, the system determines normalized differences from the MTM valuations and notional values. At block 220, the system determines percent differences from the FX data. These two outputs then feed into block 225.

[0091] At block 225, the system determines the distances between the normalized and percent differences. At block 230, the system uses the distances between the normalized and percent differences to determine the optimal distance and the associated snap time prediction. The optimal distance may be a minimal value in a vector of distances, and the corresponding snap time likely indicates a probable time the valuation was captured.

[0092] The outcomes of these determinations may be utilized in the dispute attribution process to verify and enhance the information on trades with FX timing issues. In the current process (described with reference to FIG.1), no additional details are provided to the parties regarding the cause of the issue, the extent of the time discrepancy, or its impact on the valuation. In the methods described herein, the snap time prediction ^^^^ and the optimal Euclidean distance ^^^^ may be employed as illustrated in FIG.3.

[0093] FIG. 3 illustrates an example timing dispute attribution 300, in accordance with example embodiments. For example, FIG.3 illustrates a process for handling FX timing issues19Atty. Dockt. No.: 24-1235-WOin a portfolio reconciliation workflow. The process, shown in the flowchart, uses a prediction accuracy test to determine if a trade has an FX timing issue, followed by a check to see if the predicted snap times for both parties are the same.

[0094] The process begins at block 305 where the system uses test data to calibrate a threshold (^) that may be used as an error margin. This threshold helps assess the accuracy of the snap timing prediction. The normalized distance (e.g., Euclidean distance), ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^, may be taken to be less than this threshold for an accurate prediction. Although the Euclidean distance is shown here for illustrative purposes, any appropriate distance or norm may be used.

[0095] At block 310, the system receives the optimal distance and associated snap time prediction (e.g., determined in the preceding process described with reference to FIG.1).

[0096] Block 315 may be configured to perform a prediction accuracy test. For example, at block 315, the system determines whether the optimal distance is less than the threshold.

[0097] Upon a determination that the optimal distance is not less than the threshold, the process moves to block 320 where the trade is labeled with an FX timing issue. Generally, an inaccurate prediction can suggest other underlying errors, such as match errors or incorrect currency bookings.

[0098] Upon a determination that the optimal distance is less than the threshold, the process moves to block 325. Block 325 may be configured to determine whether the snap time prediction is the same for both parties.

[0099] A determination that the snap time prediction is the same for both parties indicates that even though a valuation difference may exist, it is not caused by an FX timing difference. In such cases, the process moves to block 330 where the FX timing is discarded as a dispute attribute.

[0100] A determination that the snap time prediction is not the same for both parties indicates that the parties are using different snap times, which may be inferred as the cause of the valuation difference. In such cases, the process moves to block 335 where the FX timing is set as a dispute attribute and the size of the error is estimated. This information can be quantified and displayed to a party.

[0101] As illustrated, depending on the outcome of the predictions, if the prediction is accurate for both sides of the trade, and the predicted snap timing is same for both sides, the trade can be labeled as correct with regards to spot rate-related differences, as illustrated in block 330.

[0102] If the prediction is accurate for both sides of the trade and the predicted snap timing is not the same for both sides, the trade would be labeled with an FX timing dispute attribution.20Atty. Dockt. No.: 24-1235-WOMoreover, the snap timing-related difference can be quantified and displayed to a party. This is illustrated in block 335.

[0103] If one or both sides of a trade have no accurate snap timing prediction, this may be flagged as an issue. Depending on how inaccurate the prediction is, it could be a sign of other underlying errors, such as match errors, incorrectly booked payment direction, wrong currency etc. This is illustrated in block 320.

[0104] FIG.4 illustrates an example reconciliation process with FX timing prediction 400, in accordance with example embodiments. For example, FIG.4 presents a suggested process for portfolio reconciliation that incorporates a new method for analyzing FX timing differences. The flowchart in FIG.4 is an enhanced version of the process shown in FIG.1.

[0105] Like in FIG. 1, the process begins with two parallel inputs: Party A's trade data is received at block 405 and Party B's trade data is received at block 410. Block 415 involves normalizing and matching these data sets against the counterparty. At block 420, the system may be configured to run tests and diagnostics to detect relevant differences, such as missing fields, incorrect currency, or mapping errors.

[0106] A significant difference over FIG. 1 is the addition of block 425 where the system determines the snap timing and distance. Such a determination may be made, for example, using approaches described with reference to FIGs.2 and 3 to calculate a probable snap timing for a party and the associated optimal distance (e.g., Euclidean distance). This process provides more detailed information on the cause of the valuation difference. The process then enters a series of decision steps, similar to those described with reference to FIG.1, but with another enhancement at the end. The initial checks are for population type issues at block 430 and valuation error type issues at block 440. If a trade has a population type issue, a match error is set as dispute attribution at block 435. If the trade has a valuation error type issue, a valuation error is set as dispute attribution at block 445.

[0107] At block 450, the process determines whether the product is eligible for an FX timing difference and that there are no significant differences in relevant economic fields. If this is the case, the process moves to block 455. Block 455 is a new resolution that does not occur in the flowchart of FIG.1. Instead of the existing approach of "FX timing is set as dispute attribution" (illustrated at block 150 of FIG.1), the resolution is at block 455 where dispute attribution for FX timing using snap timing prediction is used. This leverages the calculations from block 425.

[0108] If there are no other differences, a valuation issue is set as dispute attribution at block 465, and if a persistent difference remains, a persistent difference is set as dispute attribution at block 470.21Atty. Dockt. No.: 24-1235-WO

[0109] FIG.4 integrates the snap timing and distance prediction at block 425 to provide a more detailed and accurate dispute attribution at block 455, which is a significant factor for resolving disagreements between parties. This enhancement allows the system to analyze valuation differences at a deeper level and provide a more precise reason for the discrepancy.

[0110] The valuation of an FX Forward, a type of OTC instrument, may be calculated using the notional amounts for a currency, the respective discount factors, and the spot exchange rate. The formulas for MTM valuation for two parties are:(Eqn.2)

[0111] is an MTM value for party 1, ^^^^2is an MTM value for party 2, ^^^^^^^^is a notional amount for currency ^^^^, ^^^^^^^^is a notional amount for currency ^^^^, ^^^^^^^^is a discount factor for currency ^^^^ between the current date and the end date of the contract, ^^^^^^^^is a discount factor for currency ^^^^ between the current date and the end date of the contract, ^^^^1is a spot rate between currency ^^^^ and ^^^^ used by party 1, and ^^^^2is a spot rate between currency ^^^^ and ^^^^ used by party 2. Both parties are obliged to reconcile the valuations of FX Forward contracts daily and resolve disputes in case there are discrepancies.

[0112] The term delta (Δ) is the first derivative of the forward price with respect to the spot price. Mathematically, it may be expressed as:^^^^^^^^^^^^ =^^^^^^^^(Eqn.3)

[0113] where ^^^^ is the forward rate, and ^^^^ is the spot rate. The Forward rate may be defined as:(Eqn.4)

[0114] In Eqn.5, the term ^^^^^^^^is the interest rate in currency ^^^^, the term ^^^^^^^^is the interest rate in currency ^^^^, ^^^^ is the time to maturity of the forward contract. The term delta may then be determined as:^^^^^^^^1 + ^^^^ × ^^^^^^^^ =^^^^ = ^^^^^^^^ 1 + ^^^^^^^^ × ^^^^(Eqn.5)22Atty. Dockt. No.: 24-1235-WO

[0115] Since the interest rate differential is typically small, the delta of an FX forward may be close to 1.

[0116] Generally, errors arising from using different FX timings can be both challenging to identify and can cause large differences in valuations. Such differences in valuations are a large factor in disputes involving FX trades. Although not confirmed due to the nature of the problem, a common perception among banks and other participants in the portfolio reconciliation workflow is that FX timing-related differences are causing a majority of the disputes of uncleared trades. Collateral disputes that remain unresolved for a period of time may cause some parties to set aside additional capital. Compliance regulations subject these disputes to be reported to regulators if they exceed a specific size and duration, resulting in unnecessary tied-up capital and increased administrative costs for banks and other participants in the OTC derivatives market.

[0117] To illustrate an example where FX timing error can be a significant driver for valuation differences, the following trade economics are assumed: currency 1: USD, currency 2: EUR,^^^^^^^^^^^^^^^^ = 100000000 ^^^^^^^^^^^^, and ^^^^^^^^^^^^^^^^ = 125000000 ^^^^^^^^^^^^. This means that party 1 willexchange 100M USD for 125M EUR at a given point in the future. For purposes of this example, let the MTM valuation date be August 31, 2021.

[0118] For simplicity, discount factors may be assumed to be the same, and that both partiesagree on using the same discounting. Accordingly, ^^^^^^^^^^^^^^^^ = ^^^^^^^^^^^^^^^^ = 1. Assume Party 1 uses11:20 UTC to capture the exchange rate, whereas Party 2 uses 16:00 UTC.

[0119] FIG.5 is an example graphical illustration 500 of an intra-day spot trade, in accordance with example embodiments. For example, FIG.5 is a line chart that plots the spot exchange rate for USD / EUR over a single day, for example, August 31, 2021. The vertical axis represents the USD / EUR spot rate, and the horizontal axis represents the time of day in UTC, from 00:00 to 23:30. The graph illustrates the fluctuation of the exchange rate throughout the day.

[0120] Two specific points in time are highlighted on the chart. A first arrow 1 points to 11:20 UTC, where the spot rate was 0.844365 USD / EUR. A second arrow 2 points to 16:00 UTC, where the spot rate was 0.847525 USD / EUR. These specific data points are used in the provided document to illustrate how using different snap times (like 11:20 UTC vs.16:00 UTC) can cause significant valuation differences between two parties in a trade. Accordingly, ^^^^1=0.844365 ^^^^^^^^^^^^ / ^^^^^^^^^^^^, and ^^^^2 = 0.847525 ^^^^^^^^^^^^ / ^^^^^^^^^^^^.

[0121] Using Eqns.1 and 2, the MTM valuation for parties 1 and 2 at the valuation date may be determined as:23Atty. Dockt. No.: 24-1235-WO= −100^^^^ ^^^^^^^^^^^^ ∗ 1 + 125^^^^ ^^^^^^^^^^^^ ∗ 0.847525^^^^^^^^^^^^ / ^^^^^^^^^^^^ ∗ 1= 5.940625^^^^^^^^^^^^^^^^

[0122] The size of the valuation difference caused by using different timings would then be:^�^^^ = ^^^^^^^^^^^^(^^^1^ + ^^^^2) = ^^^^^^^^^^^^( −5545625 + 5940625 ) = 395000 ^^^^^^^^^^^^

[0123] Generally, the difference in valuation between party 1 and 2 for an FX forward may depend on factors including different assumptions on interest rate curves for the two sides of the trade, and different spot rates used to translate the notional amount. This assumes that the match is correct, meaning the contract from party 1 side is matched with the same contract on party 2 side. If this is not the case, this may be determined to be a match error. It also assumed both parties report the same trade economics, i.e. notional amounts, currencies etc. If there is a difference in reported trade economics, this may be determined to be a booking error.

[0124] In some embodiments, different spot rates may be used, caused by the two sides using different times of day to capture the spot rate. Different spot rates may be detected by looking at the day-to-day percentual change for the valuation of the trade and matching it against the respective change for the underlying spot rate. The percentual change of the valuation in this context generally refers to how much the value of the notional has changed when it is valued in the currency corresponding to the other notional. Assuming a discount factor close to 1, the percentual changes used in the calculations may be calculated from the MTM values as:(Eqn.6)

[0125] In Eqn.6, ^^^^^^^^represents the MTM value at day ^^^^, and ^^^^ is the notional amount. Both valuation and notional value are shown in whatever currency is agreed on in the contract as the MTM valuation currency. Notice that subscript for denoting which side the valuation is for, party 1 or party 2, is dropped to enhance clarity as it is not relevant for the illustration.

[0126] The spot rate at day ^^^^, at time ^^^^, may be represented as ^^^^^^^^,^^^^and may be determined by the following relation:^^^^ ^^^^24Atty. Dockt. No.: 24-1235-WO(Eqn.7)

[0127] Here, ^^^^ refers to the time of day when the spot rate was captured and is the unknown variable. The portfolio reconciliation industry refers to the time of day a spot rate is captured as FX timing or snap timing, and this terminology is adhered to herein.

[0128] Since the delta of an FX forward is close to 1, it may be assumed that a percentual difference in spot rate from one day to the next may likely lead to a similar percentage change in the valuation of the trade. The goal is therefore to find the snap timing ^^^^ so that:(Eqn.8)

[0129] Accordingly, the daily percentage difference for the valuation of an FX forward may be determined to be as close as possible to the movement of the spot rate for the same currency pair. Such a relationship is likely to hold for days of the trade, which may be determined in the following manner: the series of day-to-day percentual differences for the contract during the time period ^^^^ may be determined and defined as:(Eqn.9)

[0130] The set of possible snap timings for the currency pair during the same period may be determined and defined as a matrix:(Eqn.10)

[0131] In Eqn.10, ^^^^ is the number of days of valuations to use, and ^^^^ are the number of possible snap timings in a day. In some embodiments, a five-minute time interval for exchangerate data may be used. This can result in a total of ^^^^ = 288 possible snap timings per day,where row 1 is mapped to the time 00:05:00, row 2 corresponds to the time 00:10:00 and so on.

[0132] To determine the distance, for illustrative purposes, Euclidean distance may be used. For example, the square root of the sum of the squared differences may be determined between25Atty. Dockt. No.: 24-1235-WOthe valuation vector ^^^^ (from Eqn.9) and row vectors ^^^^^^^^in the matrix ^^^^ (from Eqn.10). The vector of distances ^^^^^^^^may be determined as:(Eqn.11)

[0133] The vector of distances may be stored for possible snap timings ^^^^ in a vector ^^^^ given as:(Eqn.12)

[0134] The predicted snap timing ^^^^ that satisfies ^^^^^^^^^^^^,^^^^ ≈ ^^^^^^^^^^^^ can be determined by taking theindex of the optimal value in the vector ^^^^ and converting that position into a snap time in a manner reversed to the one described above.

[0135] The prediction of snap timing may be represented geometrically with finding the geometric “distance” d between two points in a Euclidean space. The snap timing vector ^^^^^^^^in the matrix ^^^^ (from Eqn.10) which is closest to the valuation vector ^^^^ would then be the one containing the spot rates that likely correspond to the movement of the valuation of the FX forward contract and may be mapped to a probable used snap timing for calculating the valuation.

[0136] FIG.6A is an example illustration 600A of determining a distance, in accordance with example embodiments. For example, FIG.6A is a technical drawing that provides a geometric representation of the distance calculation. The figure shows three vectors, ^^^^1, ^^^^2, and ^^^^3, which represent a series of daily percent differences for possible spot rate timings. A fourth vector, ^^^^, represents the series of daily normalized percent differences for the trade's valuation. The figure illustrates how the "distance" between the valuation vector (^^^^) and the possible spot rate vectors (^^^^1, ^^^^2, and ^^^^3) may be determined. The distance shown, ^^^^^^^^2^^^^, is the optimal distance between the valuation vector (^^^^) and a specific snap timing vector (^^^^2). This is the optimal distance, which corresponds to the probable snap timing used for the valuation. Geometrically, the snap timing vector (^^^^2) that is closest to the valuation vector (^^^^) is the one that likely corresponds to the movement of the trade's valuation.

[0137] The assumption that trades maintain substantially consistent snap timing throughout their duration or that no other issues arise does not hold in many cases. Accordingly, a method26Atty. Dockt. No.: 24-1235-WOfor assessing the accuracy of snap timing predictions can be useful. To determine an accurate prediction, a threshold value ^^^^ for the computed distance can be calibrated by comparing a large number of trades across various party relationships and currency pairs. This threshold can be validated against the reference data to ensure an appropriate predictive accuracy. When performing threshold comparisons, the length of vectors ^^^^ and ^^^^ —representing the number of days used in the calculations—may be considered. The more the number of days that are included, the lower the normalized distance (^^^^) is expected. In some embodiments, for anaccurate prediction, ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ < ^^^^ , may be used, where(Eqn.13)

[0138] with ^^^^ representing the number of days used, and ^^^^ the prediction accuracy threshold for normalized distances.

[0139] FIG.6B is an example distribution 600B of a number of trades based on a distance per trade, in accordance with example embodiments. For example, FIG.6B illustrates a histogram that plots the number of trades on the vertical axis against the distance on the horizontal axis. The histogram shows the distribution of trades within a specific relationship based on the lowest distance value. This distance is a measure of the accuracy of the snap timing prediction. The lower the Euclidean distance, the higher the accuracy of the snap timing prediction.

[0140] The histogram illustrates a concentration of trades with low distances, with the highest bar appearing around a distance of 0.0001. A dashed vertical line 605 is shown at a distance of approximately 0.0005, which represents a calibrated threshold. Trades to the left of this line have a low enough distance to be considered accurate predictions. This threshold may be derived from the distribution of various trade populations and may be adjusted depending on the target level of precision. Trades with a distance below this threshold are considered to have an accurate snap timing prediction.

[0141] . In this example, the threshold has been set at 0.0005 derived from the distribution of various trade populations and may, at a later stage, be compared against validation data provided by clients on the actual timing of the spot rate. Depending on what level of precision is targeted, the threshold may be lowered or raised accordingly. A lower threshold would ensure higher precision but would imply that fewer trades can be labeled. The more days that are used for comparing spot rates with respect to valuations, the accuracy of the prediction may likely increase and thus the threshold may be adjusted accordingly.27Atty. Dockt. No.: 24-1235-WO

[0142] When comparing multiple trades for a party / counterparty relation with respect to different trade books, currency pairs or combinations of entities, it is possible to identify patterns in snap timing differences between the two sides of a collection of trades. The plot in FIG. 7 illustrates an example, where the black points represent trades where the estimated snap timing is the same for both parties, and the gray points represent trades where the predicted snap timings are different, causing valuation differences.

[0143] FIG.7 is an example distribution 700 of a collection of trades based on predicted snap timings for a side of the trade, in accordance with example embodiments. For example, FIG.7 is a scatter plot that illustrates the estimated snap timings for Party 1 and Party 2 for a collection of trades. The horizontal axis represents the predicted snap timing for Party 1 in UTC hours, and the vertical axis represents the predicted snap timing for Party 2 in UTC hours. The size of a point on the plot corresponds to the number of trades with that specific combination of snap timings.

[0144] The plot uses two different shades to categorize the trades. Black points (e.g., black point 705) represent trades where the estimated snap timing is the same for both parties, indicating that they likely used the same time to value their trades. Gray points (e.g., black point 710) represent trades where the predicted snap timings are different for a party, which causes valuation differences.

[0145] As the plot indicates, a majority of trades are correctly matched with their respective counterparty, where the majority of trades are using the snap timing of 15:00 or 16:00 UTC, which corresponds to London Stock Exchange closing time, and is commonly used as an industry-standard. An example of a timing difference is shown by a gray cluster in the upper left of the plot, where the predictions suggest Party 1 uses 06:00 UTC and Party 2 uses 15:30 UTC.

[0146] To illustrate, snap timing prediction may be performed on a USD / EUR FX forward, where the time period used can be four days between August 31, 2021, and September 3, 2021. The generated valuations have used snap timings for which the spot rates are captured as party 1: 11:20 UTC, and party 2: 05:10 UTC. The FX rate for USD / EUR may be retrieved and represented in tabular format:28Atty. Dockt. No.: 24-1235-WOTable 1

[0147] The day-to-day percentage difference for a snap timing may be determined as:Table 2

[0148] From the uploaded valuation data from a client, the MTM valuation values may be stored as:Table 3Table 4

[0149] The distance may be determined for the two valuation vectors against a snap timing, where an optimal (e.g., minimal) distance would be the predicted snap timing for a valuation. In some embodiments, the distance may be normalized using the number of days used for the calculations (in this case 4). FIG.8 illustrates the distances for 288 possible combinations:29Atty. Dockt. No.: 24-1235-WO

[0150] FIG. 8 is an example graphical illustration of a distance in mark-to-market (MTM) valuations, in accordance with example embodiments. FIG.8 is composed of two bar charts, 800A and 800B, which illustrate the results of calculating distances (e.g., Euclidean distances) to determine the predicted snap timing for two different parties' MTM (mark-to-market) valuations. Both charts display the Euclidean distance on the vertical axis and the time of day on the horizontal axis. The distance may be computed between a valuation vector and a vector of day-to-day spot rate changes for possible snap timings. For example, the lowest value in thevector of distances, represented by the arrow labeled “^^^^ = ^^^^^^^^^^^^^^^^^^^^^^^^(^^^^)” (arrow 3 in chart800A and arrow 4 in chart 800B)) may be taken to correspond to an optimal snap timing prediction for a party.

[0151] Chart 800A illustrates distance MTM valuation 1. The lowest distance value is identified around 11:20 UTC, which, according to the provided example, is the predicted snap timing for Party 1. The first dashed line 805 on chart 800A represents the accuracy threshold, ^^^^, which is set at 0.001 in the example. The minimal distance for Party 1 is shown to be below this threshold, indicating an accurate prediction.

[0152] Chart 800B illustrates distance MTM valuation 2. The lowest distance value is identified around 05:10 UTC, which, according to the provided example, is the predicted snap timing for Party 2. Similar to Chart 800A, the minimal distance for Party 2 is also below thethreshold of ^^^^ = 0.001 (indicated by a second dashed line 810), classifying it as an accurateprediction. The difference in the predicted snap timings for Party 1 (11:20 UTC) and Party 2 (05:10 UTC) would explain the valuation difference between them.

[0153] The lowest distance to the MTM valuation vector is found for party 1 at 11:20 UTC, and for party 2 at 05:10 UTC. The accuracy of the prediction is given by the distance itself,which is dependent on what threshold ^^^^ is set to be. In this example, a threshold of ^^^^ = 0.001is used, meaning that both distances are below the threshold and the prediction is classified as an accurate prediction.

[0154] A detected discrepancy in predicted snap timings would be significant information for clients to understand why there is a valuation difference as well as how to resolve the issue. Given that both parties would have had the same snap timing, the remaining valuation difference could then be derived from other factors such as use of different discount factors.

[0155] The techniques described herein have versatile applications across numerous areas. In the OTC derivatives market, it can be beneficial for instruments whose valuation depends on fluctuating prices or exchange rates throughout the day. This includes various types of foreign30Atty. Dockt. No.: 24-1235-WOexchange (FX) instruments not limited to FX forwards, as well as commodity forwards like oil and gold. Additionally, power purchase agreements, where electricity prices vary throughout the day, are potential candidates for this approach. Also, for example, the techniques described herein may be applied to cross-currency swaps.Example Computing Environment

[0156] FIG.9 depicts a distributed computing environment 900, in accordance with example embodiments. Distributed computing environment 900 includes a trade reconciliation platform 910 (e.g., a server device, a distributed system, a hybrid cloud, a cloud server, and so forth) that is configured to communicate, via network 905, with one or more computing devices, such as a tablet device 915, a smartphone device 920, and a desktop 925. These devices are connected to the network 905, enabling users to access the trade reconciliation platform 910 and its services, such as portfolio reconciliation. The setup depicts a centralized system where a single platform processes data from multiple users through a network connection. Network 905 may correspond to a local area network (LAN), a wide area network (WAN), a WLAN, a WWAN, an intranet, a public Internet, or any other type of network configured to provide a communications path between networked computing devices. Network 905 may also correspond to a combination of one or more networks. The trade reconciliation platform 910 is where the MTM valuations are processed.Example Computing Device

[0157] FIG.10 is a block diagram illustrating an example computer device 1000, in accordance with example embodiments. Example computer device 1000 may include one or more computing devices of FIG.9, such as a trade reconciliation platform 910, a tablet device 915, a smartphone device 920, and a desktop 925.

[0158] Computing device 1000 may include modules to provide various functionalities, such as for example, an input / output (I / O) bus interface 1005, a network controller 1015, a processor 1020, memory 1030, and display interface 1040, which may be linked together via a system bus, or other connection mechanism 1050.

[0159] Input / output (I / O) bus interface 1005 can be configured to send data to and / or receive data from peripheral devices 1010 such as a touch screen, a computer mouse, a keyboard, a microphone, external monitors, and the like.

[0160] Network controller 1015 can be configured to provide one or more wireless interface(s) and / or one or more wireline interface(s) that can be configured to communicate with a network31Atty. Dockt. No.: 24-1235-WO(e.g., network 905 of FIG.9). This network connectivity allows the device to interact with other systems, such as the trade reconciliation platform 910 of FIG. 9. Wireless interface(s) can include wireless transmitters, receivers, and / or transceivers (e.g., for Bluetooth, Wi-Fi, near-field communications, etc.). Wireline interface(s) can include wireline transmitters, receivers, and / or transceivers (e.g., Ethernet transceiver).

[0161] Processor 1020 can include a general-purpose processor, and / or special purpose processors (e.g., digital signal processors, graphics processing units (GPUs) such as a graphics processor 1025, media processing processors, image processing processors, text processing processors, speech processing processors, etc.). Processor 1020 can be configured to execute computer-readable instructions 1035 that are contained in memory 1030 and / or other instructions as described herein.

[0162] Memory 1030 can include one or more non-transitory computer-readable storage media that can be read and / or accessed by processor 1020. The one or more computer-readable storage media can include volatile and / or non-volatile storage components. In some examples, memory 1030 can be implemented using a single physical device, while in other examples, memory 1030 can be implemented using multiple physical devices.

[0163] Memory 1030 can include computer-readable instructions 1035 that, when executed by processor 1020, enable computing device 1000 to provide for some or all of the functionality of the computing devices described herein.

[0164] The operations include receiving, at a trade reconciliation platform (e.g., trade reconciliation platform 910 of FIG.9) and over a communications channel, a first valuation data for a financial instrument from a first computing device associated with a first counterparty, and second valuation data for the financial instrument from a second computing device associated with a second counterparty. The operations further include determining, by a server-side processor of the trade reconciliation platform, a first predicted snap timing for the first valuation data and a second predicted snap timing for the second valuation data. The operations also include comparing, by the server-side processor, the first predicted snap timing to the second predicted snap timing to detect a timing discrepancy between the first and second counterparties. The operations further include generating, by the trade reconciliation platform, a digital dispute report indicating the timing discrepancy as a cause of a valuation discrepancy. The operations additionally include sending, over the communications channel, the digital dispute report to the first and second computing devices for an automated resolution of the valuation discrepancy.32Atty. Dockt. No.: 24-1235-WO

[0165] Display interface 1040 can be configured to send data to and / or receive data from external user input / output display devices 1045 such as a touch screen, external monitors, and the like. Display interface 1040 can also be configured to generate audio and / or video outputs.Example Methods of Operation

[0166] FIG. 11 is a flowchart of an example method, in accordance with example embodiments. Method 1100 may include various blocks or steps. The blocks or steps may be carried out individually or in combination. The blocks or steps may be carried out in any order and / or in series or in parallel. Further, blocks or steps may be omitted or added to method 1100.

[0167] The blocks of method 1100 may be carried out by various elements of computing device 1000 as illustrated and described in reference to FIG.10.

[0168] Block 1110 involves receiving, at a financial trade reconciliation platform, real-time market data over a communications channel.

[0169] Block 1120 involves determining, by a server-side processor of the trade reconciliation platform, a first predicted snap timing for the first valuation data and a second predicted snap timing for the second valuation data.

[0170] Block 1130 involves comparing, by the server-side processor, the first predicted snap timing to the second predicted snap timing to detect a timing discrepancy between the first and second counterparties.

[0171] Block 1140 involves generating, by the trade reconciliation platform, a digital dispute report indicating the timing discrepancy as a cause of a valuation discrepancy.

[0172] Block 1150 involves sending, over the communications channel, the digital dispute report to the first and second computing devices for an automated resolution of the valuation discrepancy.

[0173] In some embodiments, the determining of the first and second predicted snap timings involves determining a valuation vector by normalizing a daily change in the received valuation data for the first and second counterparties. Such embodiments also involve receiving a reference data set of spot rates and calculating a matrix of spot rate vectors, wherein a spot rate vector represents a daily percentage change in a spot rate for a specific time of day. Such embodiments further involve determining a vector of distances by comparing the valuation vector to spot rate vectors. Such embodiments also involve identifying the first and second predicted snap timings by determining a time of day corresponding to a minimum value in the vector of distances.33Atty. Dockt. No.: 24-1235-WO

[0174] In some embodiments, the vector of distances may be based on one of a Euclidean distance, a Manhattan distance, a cosine similarity, a correlation coefficient, or a Dynamic Time Warping (DTW) algorithm.

[0175] In some embodiments, the first and second valuation data may include a series of daily mark-to-market (MTM) valuation reports for an over-the-counter (OTC) financial instrument.

[0176] Some embodiments involve calibrating a threshold using test data to be used as an error margin.

[0177] Some embodiments involve executing a prediction accuracy test by determining if a normalized minimal distance for both the first and second valuation data is below the calibrated threshold.

[0178] In some embodiments, if the prediction accuracy test fails for at least one of the first or second valuation data, the digital dispute report may be generated to indicate a different underlying error, wherein the different underlying error include a match error, or an incorrect booking of payment direction or currency.

[0179] In some embodiments, the financial instrument may be a foreign exchange (FX) forward contract.

[0180] In some embodiments, the financial instrument may be a commodity forward contract.

[0181] In some embodiments, the financial instrument may be a power purchase agreement.

[0182] In some embodiments, the financial instrument is a foreign exchange (FX) instrument not limited to FX forwards.

[0183] In some embodiments, the financial instrument may be a cross-currency swap.

[0184] In some embodiments, the automated resolution involves providing the predicted snap timings to the first and second counterparties to enable synchronization of their timing.

[0185] In some embodiments, the digital dispute report further includes a quantified size of an error caused by the timing discrepancy.

[0186] In some embodiments, the trade reconciliation platform, the first computing device, and the second computing device may be connected through a network.

[0187] In some embodiments, the trade reconciliation platform may be a component of a portfolio reconciliation service.

[0188] In some embodiments, the portfolio reconciliation service may be for bilateral over-the-counter (OTC) derivatives.

[0189] In some embodiments, the portfolio reconciliation service may facilitate reconciliation for over 90% of bilateral OTC derivatives globally.34Atty. Dockt. No.: 24-1235-WO

[0190] In some embodiments, the first and second valuation data may include mark-to-market (MTM) values and notional amounts.

[0191] In some embodiments, the first and second valuation data may include discount factors for a currency of the financial instrument.

[0192] In some embodiments, the determining of the first and second predicted snap timings may be based on a comparison of a normalized daily percentage change of the valuation data and a daily percentage change of spot exchange rates.

[0193] In some embodiments, the generated digital dispute report may include a match error report indicating a population type issue related to matching the first and second valuation data.

[0194] In some embodiments, the generated digital dispute report may include a valuation error report indicating a valuation error, such as a missing mark-to-market (MTM) currency.

[0195] In some embodiments, the generated digital dispute report may include a persistent difference report indicating a remaining discrepancy after other potential causes have been eliminated.

[0196] In some embodiments, the first counterparty may be a bank, and the second counterparty may be a client.

[0197] In some embodiments, the first and second counterparties may be financial institutions.

[0198] In some embodiments, the first counterparty may be a financial institution, and the second counterparty may be a corporation.

[0199] The present disclosure is not to be limited in terms of the particular embodiments described in this application, which are intended as illustrations of various aspects. Many modifications and variations can be made without departing from its spirit and scope, as will be apparent to those skilled in the art. Functionally equivalent methods and apparatuses within the scope of the disclosure, in addition to those enumerated herein, will be apparent to those skilled in the art from the foregoing descriptions. Such modifications and variations are intended to fall within the scope of the appended claims.35

Claims

Atty. Dockt. No.: 24-1235-WOCLAIMSWhat is claimed is:

1. A computer-implemented method performed by a trade reconciliation platform for improving an efficiency and accuracy of a financial trade reconciliation platform, comprising:receiving, at the trade reconciliation platform and over a communications channel, a first valuation data for a financial instrument from a first computing device associated with a first counterparty, and second valuation data for the financial instrument from a second computing device associated with a second counterparty;determining, by a server-side processor of the trade reconciliation platform, a first predicted snap timing for the first valuation data and a second predicted snap timing for the second valuation data;comparing, by the server-side processor, the first predicted snap timing to the second predicted snap timing to detect a timing discrepancy between the first and second counterparties;generating, by the trade reconciliation platform, a digital dispute report indicating the timing discrepancy as a cause of a valuation discrepancy; andsending, over the communications channel, the digital dispute report to the first and second computing devices for an automated resolution of the valuation discrepancy.

2. The method of claim 1, wherein the determining of the first and second predicted snap timings further comprises:determining a valuation vector by normalizing a daily change in the received valuation data for the first and second counterparties;receiving a reference data set of spot rates and calculating a matrix of spot rate vectors, wherein a spot rate vector represents a daily percentage change in a spot rate for a specific time of day;determining a vector of distances by comparing the valuation vector to spot rate vectors; andidentifying the first and second predicted snap timings by determining a time of day corresponding to a minimum value in the vector of distances.36Atty. Dockt. No.: 24-1235-WO3. The method of claim 2, wherein the vector of distances is based on one of a Euclidean distance, a Manhattan distance, a cosine similarity, a correlation coefficient, or a Dynamic Time Warping (DTW) algorithm.

4. The method of claim 1, wherein the first and second valuation data comprises a series of daily mark-to-market (MTM) valuation reports for an over-the-counter (OTC) financial instrument.

5. The method of claim 1, further comprisingcalibrating a threshold using test data to be used as an error margin.

6. The method of claim 5, further comprisingexecuting a prediction accuracy test by determining if a normalized minimal distance for both the first and second valuation data is below the calibrated threshold.

7. The method of claim 6, wherein if the prediction accuracy test fails for at least one of the first or second valuation data, the digital dispute report is generated to indicate a different underlying error, wherein the different underlying error comprises a match error, or an incorrect booking of payment direction or currency.

8. The method of claim 1, wherein the automated resolution further comprising:providing the predicted snap timings to the first and second counterparties to enable synchronization of their timing.

9. The method of claim 1, wherein the digital dispute report further comprises a quantified size of an error caused by the timing discrepancy.

10. The method of claim 1, wherein the trade reconciliation platform, the first computing device, and the second computing device are connected through a network.

11. The method of claim 1, wherein the financial instrument is a foreign exchange (FX) forward contract.37Atty. Dockt. No.: 24-1235-WO12. The method of claim 1, wherein the financial instrument is a commodity forward contract.

13. The method of claim 1, wherein the financial instrument is a power purchase agreement.

14. The method of claim 1, wherein the financial instrument is a foreign exchange (FX) instrument not limited to FX forwards.

15. The method of claim 1, wherein the financial instrument is a cross-currency swap.

16. The method of claim 1, wherein the trade reconciliation platform is a component of a portfolio reconciliation service.

17. The method of claim 16, wherein the portfolio reconciliation service is for bilateral over-the-counter (OTC) derivatives.

18. The method of claim 16, wherein the portfolio reconciliation service facilitates reconciliation for over 90% of bilateral OTC derivatives globally.

19. The method of claim 1, wherein the first and second valuation data comprise mark-to-market (MTM) values and notional amounts.

20. The method of claim 1, wherein the first and second valuation data comprise discount factors for a currency of the financial instrument.

21. The method of claim 1, wherein the determining of the first and second predicted snap timings is based on a comparison of a normalized daily percentage change of the valuation data and a daily percentage change of spot exchange rates.

22. The method of claim 1, wherein the generated digital dispute report comprises a match error report indicating a population type issue related to matching the first and second valuation data.38Atty. Dockt. No.: 24-1235-WO23. The method of claim 1, wherein the generated digital dispute report comprises a valuation error report indicating a valuation error, such as a missing mark-to-market (MTM) currency.

24. The method of claim 1, wherein the generated digital dispute report comprises a persistent difference report indicating a remaining discrepancy after other potential causes have been eliminated.

25. The method of claim 1, wherein the first counterparty is a bank, and the second counterparty is a client.

26. The method of claim 1, wherein the first and second counterparties are financial institutions.

27. The method of claim 1, wherein the first counterparty is a financial institution, and the second counterparty is a corporation.

28. A computing device for improving an efficiency and accuracy of a financial trade reconciliation platform, comprising:one or more processors; anddata storage, wherein the data storage has stored thereon computer-executable instructions that, when executed by the one or more processors, cause the computing device to perform steps in accordance with the computer-implemented method of any one of claims 1-27.

29. A computer program for improving an efficiency and accuracy of a financial trade reconciliation platform comprising instructions that, when executed by a computer, cause the computer to perform steps in accordance with the computer-implemented method of any one of claims 1-27.

30. An article of manufacture for improving an efficiency and accuracy of a financial trade reconciliation platform comprising one or more non-transitory computer readable media having computer-readable instructions stored thereon that, when executed by one or more39Atty. Dockt. No.: 24-1235-WOprocessors of a computing device, cause the computing device to perform steps in accordance with the computer-implemented method of any one of claims 1-27.

31. A system for improving an efficiency and accuracy of a financial trade reconciliation platform, comprising instructions that, when executed by a computer, cause the computer to perform steps in accordance with the computer-implemented method of any one of claims 1-27.40

Images