A trade snapshot in Findur is an archived version of a trade that preserves its state. With the passage of time, lifecycle processing and events affect a trade’s state: trades in fungible instruments may be paired-off and closed out, and OTC trades might be exercised, terminated and more.
The snapshot may be used to restore a trade to a prior state, or to run a simulation to recreate results applicable for the trade in that state.
Saving your first trade snapshot is easy. Knowing how to reroute downstream processes to use trade snapshots is a lot more difficult. User defined sim results, reports, extracts and accounting need to be snapshot-aware. Openlink has no out-of-the-box content for taking, managing or using trade snapshots. Long-term, you will also need to keep an eye on database growth and performance.
Why Might I Need Trade Snapshots?
We have implemented trade snapshots, in conjunction with Sim Tasks, for users that needed to rerun a recent month’s closing simulations after making revisions to some pricing inputs. We released a paper with additional information about sim tasks; read it here.
Other clients want the ability to regenerate reports for any prior date, including the set of transactions as of that date in their prevailing state. In Findur, the ability to regenerate reports for a prior date can add a significant amount of complexity to a report. We have been down that road and delivered to these specifications. This paper shares information about how these complex requirements can be resolved in Findur.
While Findur has native support for restoring a previous version of a trade, in the event that the trade is processed incorrectly, there are some amendments for which the restore previous transaction feature may not be supported. You must be confident of having a pre-amendment snapshot available. Automated snapshotting is easy to implement to cover these gaps; we have a solution for that.
Sim Trade Snapshot Definitions
There are three ways to take a trade snapshot. The quickest way for an individual trade is available manually from the trade window by selecting Misc | Save as Trade Snapshot.
The second way to take a snapshot is to create a Sim Trade Snapshot definition and use the definition to take a snapshot. This method will most commonly be used to capture a snapshot for more than one trade.
The third method for taking snapshots is via the OpenJVS or OpenComponents API. Most commonly, an API is used to automate taking snapshots using a sim trade snapshot definition.
First we will look at sim trade snapshot definitions in more depth. How they are setup and how they are used. We have more information at the end of this post about the OpenJVS and OpenComponents API, used for automation of the operations.
Sim Trade Snapshots: Definition Setup
A sim trade snapshot definition is a feature that was designed, together with sim tasks, to be able to run simulations on trades as of a specific date.
The snapshot definition has two properties: name and query.
- The snapshot definition name will be stamped as a reference on any snapshot that is taken.
- The snapshot definition’s query property governs the transactions associated with the definition.
Snapshot definitions exist to facilitate taking snapshots of a collection of trades, typically grouped by portfolio. When a user uses a snapshot definition to take a snapshot, Findur will run the transaction query, and take a snapshot of each of the transactions.
The most common implementation of snapshot definitions involves the configuration of transaction queries that group trades by portfolio. For each portfolio in the system, there will be a saved query to retrieve its live trades. For each portfolio in the system, there will be a snapshot definition that uses the portfolio’s saved query.
You may choose to group trades by criteria other than portfolio. For example, if you want to take a snapshot of all bilateral OTC trades for collateral management purposes, you can certainly take a snapshot of all live OTC trades in all portfolios where there is a valid ISDA agreement.
Sim Trade Snapshot: Taking
From a Data Explorer desktop, a user can select a snapshot definition and click the Take Snapshot button to take the snapshot. The user will need to select a snapshot type.
The snapshot type property defines its purpose. For example the snapshot type EOD could be used to indicate that the snapshot was taken during the EOD workflow. Another snapshot type, Collateral, could be an indication that the snapshot contains collateral and OTC exposures used for collateral management. Snapshot type is static data and, like most other static data elements in Findur, new ones can be created easily.
If there is already a snapshot that matches the compound key of {snapshot name, snapshot type, and snapshot date}, the operation will fail. The system does not permit duplicate sim trade snapshots.
Trade Snapshot Use Cases
Use Case: Rerunning Prior Day or Prior Month-End Simulations
Let’s look at the most frequent use case that necessitates the configuration of snapshot definitions: rerunning prior day, or prior month-end simulations. Prior day simulations can be run using the reval window on the latest version of trades, but if an OTC instrument was terminated, the result of the reval will reflect the terminated trade, rather than its state prior to termination.
The only way to rerun simulations as of a prior day, while ensuring that the version of the trade matches its state on that same day, is to have a snapshot of the portfolio available from the prior day, and to use the snapshot to run a sim task.
Sim tasks are easy to setup and run, although there is no standard Openlink plugin to do it. We have another paper with more information about sim tasks, or you could reach out for help.
Use Case: Regenerating Historical Reports
Some clients (most, if not all?) would expect to have the ability to run reports for a prior day and expect the results to include (a) all trades that were live on that date (b) only trades that were live on that date, and (c) all trades to be in the state effective as of that date. Findur is not naturally setup to support this use case.
Findur is designed to retain a single copy of a transaction: the latest version, including any necessary corrections and historical events. All business intelligence is expected to be performed on the latest and greatest version of a trade. Using this design intention is expected to deliver the highest quality, most predictable results for business-critical operations such as cash forecasting, payment settlements, risk, accounting, and more.
The single-version design intent creates a gap when users need to see certain reports regenerated as of a prior date. The easiest way to resolve this requirement is, of course, to generate and extract to a network drive all production reports everyday. Users will be able to use the historical copy of the report from the file system. For a variety of reasons, this is insufficient for some organizations, and it can become necessary to plan, for each report, a solution.
Some data in Findur can quite easily resolve the as of reporting requirements. Reports on accounting data can often be regenerated quite easily. Journal entries and balances are retained in the system, and with a tool like Report Builder, the data is easily re-extracted for any parameter date for which the data was generated.
Historical simulation data can be retrieved as well using Report Builder. Simulation data usually includes valuation, pricing inputs, price sensitivities, P&L, and even projected cash flows. If the as of reporting requirement extends beyond this metadata, analysts would usually retrieve additional transaction data from the database. Care must be taken here: if the transaction’s state has changed since the as of report date, the data returned from the database might be inconsistent with the historical state of the transaction. The easiest way to resolve this is to extract all of the necessary transaction reporting metadata into a simulation result. We would recommend designing the solution to use a simulation result because then it can be extracted using the trade’s historical snapshot.
Trade Snapshot Traps
An implementation of trade snapshots adds complexity to the application. There are several parts of the application that will need more attention to ensure the trade snapshots are being taken, accurately reflect the right trade state at the right time, and is being used in downstream reporting and extracts where it is necessary.
User-defined sim results, reports, extracts and accounting need to be snapshot-aware. Openlink has no out-of-the-box content for taking, managing or using trade snapshots. Long-term, you will also need to keep an eye on database growth and performance.
Trap: User Defined Simulation Results Don’t Use The Snapshot
When using a sim task, native simulation results such as MTM, and Current Notional, will operate on the trade snapshot, observing the specified transaction state. Users will, however, sometimes notice problems with user-defined simulation results (UDSRs). A lot of UDSRs are designed to retrieve transaction data from the database. The database will have the latest version of the trade, so the UDSR will not respect the trade snapshot version. Look out for this.
The most commonly observed UDSR that has this gap is the Effective Yield Amortization result, implemented as a UDSR. The only way for the UDSR to use the trade snapshot is to ensure the solution does not retrieve data from the database that could reflect a different version of the trade.
Trap: Trade Lifecycle Processing And Trade Corrections
It is important to outline the expected results for rerunning historical simulations, and as of reporting when it comes to trade corrections. Findur does not distinguish between a trade amendment made the result of a lifecycle event such as a termination, and an amendment made to correct a trade entry error.
If the original terms on the trade were booked incorrectly in Findur, then the pricing, accrual, sensitivities, P&L and more, could be wrong. Sometimes, trade entry error is discovered late, perhaps when it comes time to settle a payment and there is a dispute over the amount with the counterparty.
Regardless of how or when trade entry errors are discovered, some organizations would seek to regenerate as of reporting use the original incorrect version of the trade. Other organizations would expect to use the version reflect the corrections, but have the trade’s state otherwise reflect all historical lifecycle events. This could be difficult, particularly if the error was discovered after a partial termination.
Let’s look at an example to make it easier to understand: a bilateral swap trade is entered incorrectly, although nobody picks up the error. The trader partially terminates the swap. The swap’s first payment date arrives, and the error is discovered. What Findur will likely need done here is to unwind the partial termination, correct the trade’s terms, update the historical snapshots from trade date to partial termination trade date, reprocess the partial termination, update the historical snapshots from termination trade date to the current date. This is a laborious, high-risk sequence of operations.
Findur does not have simple out-of-the-box support for backdating corrections, while replaying historical lifecycle events. In that language of software engineering, Findur’s transactions are stateful, and replaying historical events, known in the industry as event sourcing, isn’t supported without additional work. Talk to us and we can discuss how to prepare for these eventualities.
System Administration
Taking trade snapshots adds to system administration. In this section we summarize topics of importance to system administrators.
Deal History
A user can view the available trade snapshots for an individual trade from the deal history window. Every snapshot available will have a check mark displayed in the Saved Snapshot column of the deal history window. Double-click on the record to view that version.
The user can also compare versions of the deal, although it is often difficult to analyze changes when presented as a table of transaction field, profile and event differences. We usually find it’s a lot easier to use the deal history window to double-click on two versions of a deal, and compare the trades side-by-side.
Security Privileges
There are security privileges controlling whether users are allowed to take snapshots, delete snapshots, create snapshot definitions, and more. Unfortunately, the security privileges are not grouped together. Search in the security window for the keyword ‘snapshot.’
Security privilege assignment is a binary operation where a user is either allowed to update snapshots, or not. There is no granularity to confine updates to the most recent month.
If you are implementing sim tasks at the same time, evaluate security privileges related to sim task setup and execution. Search for the keyword ‘sim task’ in the security privileges window.
End of Day Configuration
If there is a use case described here that has required you to take snapshots and use sim tasks, there are several tasks that should be added to the end of day configuration.
- Create Snapshot Definitions: creates a query and snapshot definition for a new portfolio
- Create Sim Tasks: creates a sim task for a new portfolio
- Take Snapshots: uses snapshot definitions to take snapshots of all portfolios
- Run Sim Tasks: runs sim tasks for all portfolios
Desktop Configuration
Sim Trade Snapshots, and Sim Trade Snapshot Definitions should be available to users to review in a desktop. Your desktops should already include a Data Explorer tab, perhaps with a different label. If you don’t have a Data Explorer tab, let us know and we will show you how to get a lot of the information operators need everyday at their fingertips.
Use the Data Explorer tab and ensure that the Sim Trade Snapshot Definition, Sim Trade Snapshot and Sim Task groups are visible. If snapshots are being taken daily on many portfolios, the number of Sim Trade Snapshots in the database will grow quickly. Create a saved query to view today’s or yesterday’s saved snapshots so the desktop performance doesn’t degrade with time. We have seen desktop crashes when there are many thousands of saved snapshots.
Purging
Trade snapshots can lead to database growth when there are many trades and state changes are frequent. The snapshots are stored in the ab_tran_snapshot table.
If you notice growth of the database, let us know. Database purge operations are risky. We have a utility for managing older, unused snapshots that may no longer be needed.
Trade Snapshot API
If you are interested in moving forward, we have sample code written using OpenJVS and OpenComponents APIs and can offer guidance on how to implement some of these features. Reach out.