Realized P&L is a simulation result in Findur that is generated on fungible instruments when a position is partially- or fully-closed out. The result is only generated on fungible instruments once a tax lot has been matched off using the Closeout Processing module.
Realized P&L is usually a straight-forward calculation, but Findur gets it wrong for a few trade types. We look at two of those trade types in this paper. In the absence of a bug fix, which Openlink would likely argue is an enhancement, we discuss methods to workaround the issue.
Closeout Processing: A Primer
The Closeout Processing module is responsible for applying a closeout definition that controls the inventory relief method, trade matching criteria, and to which side of the trade the realized P&L is recognized (the original tax lot or the matched off trade).
Once the trades have been paired off, the realized P&L will be generated and attributed in the EOD simulation results. The paired-off transaction details are stored in the database in the tran_match table.
Inflation-Linked Bonds
Bond realized P&L is calculated on the face amount from trade price of the purchase to trade price of the sale (let’s assume a long position in this paper, although Findur is equally capable of handling short positions).
Bond instruments are configured to have a price type that governs whether the market price of the instrument is clean or dirty. If the bond is an inflation-linked bond then the price type may be inflation-adjusted or unadjusted. An additional field controls whether the instrument is marked-to-market using a market price or market yield.
U.S. T-Notes are priced clean. U.S. TIPS are priced clean without inflation-adjustment. Market prices on Australian Commonwealth Government Bonds are dirty without inflation-adjustment.
The price type configuration controls not only pricing, but also the calculation of realized P&L. This dual-purpose use of price type creates a problem for the calculation of realized P&L.
Realized P&L on U.S. T-Notes is calculated on the clean price so there is no conflict between the price type required for marking-to-market, and price type required to calculate realized P&L. Using the closeout processing module to control inventory relief and the simulation engine to calculate realized P&L produces the correct results for realized P&L.
The same cannot be said for U.S. TIPS. The market price on TIPS is clean, and not inflation-adjusted. The simulation engine calculates the inflation compensation, and accrued interest, and returns the correct market value for the TIPS position.
When a TIPS position is closed out, the Closeout Processing module matches the inventory, and leaves the simulation engine to calculate realized P&L. The simulation engine uses the price type configured on the bond, which does not include inflation compensation. Realized P&L on an inflation-linked bond should be calculated from the inflated clean price of the purchase to the inflated clean price of the disposal. Findur’s calculation of realized P&L on inflation–linked bonds is incorrect.
Conventional Options on Futures
Conventional options on futures are listed options with a futures underlying that have an upfront premium. There is no daily settlement of variation margin.
These instruments belong in Findur to the FinETO or ComOptFut toolsets. FinETO is short for Financial Exchange Trade Option. ComOptFut is short for Option on Commodity Futures.
There are two fields that are important to model a conventional future option –
- The Premium Creation field should be set to Settlement, to generate a premium at the start of the trade
- The Margin Type field should be set to None, to suppress daily generation of variation margin
Findur incorrectly recognizes Realized P&L on conventional options on the settlement date of the upfront premium.
When a position is partially- or fully-closed out, realized P&L is generated, but since the realized P&L was generated on the premium settlement date, the life-to-date realized P&L is incorrect, so the result cannot be used for reporting to the general ledger.
Depending on your operational processes, expiration, or exercising of the options may also require attention. Some clients choose to create notional ‘maturity’ trades for some instruments to model the expiry or exercise of a trade. Findur does not require these maturity trades to model the expiry/exercise events, but it can simplify downstream processing in some cases.
Solutions Available
In this section, we discuss some solutions considered for closing these realized P&L gaps.
Instrument Configuration
The first solution to consider is whether there is a configuration change that may close the gaps. For inflation-linked bonds, we already addressed the deficiency of dual-purpose of the price type field for valuation and realized P&L calculations. There are no other instrument fields available to fix the problem.
Grid Point Configuration
In some cases, it is possible to workaround pricing issues by introducing a formula to the market price grid point of the instrument. There are a lot of functions available to control pricing, but inflation compensation is not one of them. Even if a function were available, for several reasons, we would question whether introducing a grid point formula would be a good idea.
The problems with realized P&L on conventional options on futures are not related to the market price so no change can or should be made to the index or grid point configuration.
Result Calculator
The result calculator extension was created, starting in v10.1. It is a licensable feature, and the extension must be written using the powerful OpenComponents API. The extension allows a developer to override native Findur results.
The clear benefit to using a result calculator extension for a result such as realized P&L is that all downstream dependent results will stand to benefit from the impact of the change. Realized P&L is a daily result, and affects Realized P&L MTD, YTD and LTD. If there is a problem with native daily result, then fixing that problem will correct MTD, YTD and LTD P&L.
We have delivered a result calculator component to a client to resolve problems with realized P&L on inflation-linked bonds and conventional options. While it resolved the gaps, we later disabled the component on performance grounds. There was one occasion when the component led the EOD simulation for a portfolio with only a handful of trades to take three hours. There was clearly a problem with the component in the C code because via logging, we could see that the additional time was not spent in the OpenComponents Java code, but in the C. The solution was always slow; 3 hours was just the most egregious incident.
We like the idea of the result calculator extension, and the ease of working with OpenComponents, but performance problems like that are unacceptable in a production environment. We aren’t sure whether Openlink has resolved the performance problem and besides, that client was unable to upgrade within a reasonable timeframe.
User-Defined Simulation Result
Until the advent of result calculators, the typical way to resolve a gap, bug, or otherwise incompletely specified simulation result was via a user-defined simulation result (UDSR). Most clients have a dozen or more UDSRs, a testament to their popularity.
As discussed in the section on result calculators, it is ideal to correct the flaw with a native result, in order for all downstream results to receive the benefit. But in the absence of a license for result calculators, or if there is a showstopping performance problem, a UDSR is a suitable solution.
UDSRs can be a good solution because they are then available downstream to Report Builder and the Accounting Desktop with only point-and-click configuration. Other customizations need only retrieve saved simulation results to gain access to the solution. UDSRs will continue to be popular amongst users, particularly when they need to rely upon trade snapshots. We discussed how important it is to design UDSRs to use trade snapshots in another paper, here.
Accounting Result
Custom accounting results are easy to create, especially if you have a robust, reusable base class to extend. A custom accounting result can be just a few lines of low maintenance code.
One of the benefits to having a custom accounting result, compared to a custom simulation result, is that if there is a change to a trade, a rule query, or the account distribution matrix, it can be faster and lower risk to rerun accounting. This is a prescriptive analysis, because if there is a change to a trade, it may be important to rerun both simulations and accounting. We take it on a case-by-case basis.
For the client who had a problem with the performance of the result calculator, we quickly refactored the solution as an accounting result, and deployed the solution within a few days. The result never takes more than a fraction of a second to complete.
Conclusions
If you see additional problems with realized P&L, let us know. We can help close the gap if Openlink is unable or unwilling to fix it. There are a lot of low-risk options to deliver reliable P&L results.
