We have previously written about gaps in Findur reporting P&L on equity derivatives, and separately on gaps in realized P&L for some instruments such as inflation-linked bonds and options on futures. In this paper, we outline another gap in Findur that affects many users: Greeks on fixed income derivatives, and by extension, P&L explained.
Why Do Users Need to See the Greeks?
Users expect Findur to be able to report Greeks on fixed income derivatives either to understand the sensitivities of their derivative exposures, or to have confidence that a book of derivatives serves as an adequate hedge to the risk of their fixed income portfolio.
The most important Greek is usually the first order interest rate sensitivity, delta, and related measures such as DV01, PV01, effective duration and key rate duration.
Users are often interested in second order sensitivity such as gamma or convexity. For fixed income derivatives with optionality, sensitivity to volatility, vega, is likely to be significant. The sensitivity to the passage of time may be significant, so theta or the cost of carry is required.
The Greeks in Findur
In Findur, there are many Greeks among the long list of simulation results. Some of the results of interest to Findur users include –
- First order interest rate risk: Tran Gpt Delta (read as ‘Tran Grid Point Delta’) and Output Delta;
- Second order interest rate risk: Gamma, and the gamma column of Tran Gpt Delta and Output Delta;
- Time sensitivity: Theta and Cost of Carry;
- Volatility sensitivity: Tran Gpt Vega, Vega
Findur has additional results that typically explain less of the P&L on an instrument, but for completeness include cross gamma (sensitivity to changes in pairs of grid points) and vega gamma (second order vol sensitivity).
Many results are available that measure the sensitivity to changes in market inputs, or market effective rates. The latter results are important, for example, when a discounting index is boostrapped using Eurodollar futures price inputs that resolve to a continuously-compounded zero rate (CCZR). A one point bump to the futures price, the grid point’s input, will produce an undesirable sensitivity result, so the discounting index’s CCZR must be shocked.
A final note on Findur’s native Greeks is that there are several that have more performant, but less accurate, approximation that initiate a parallel shock to the index. Parallel Index Output Delta measures an instrument’s sensitivity by shifting all grid points’ effective rates, instead of shifting them one at a time.
Gaps in Findur’s Fixed Income Derivative Greeks
For many fixed income derivatives, Findur’s native first and second order sensitivities cannot be used out-of-the-box.
When a fixed income derivative instrument is captured, it is linked to the underlying bond security master definition. The problems in Findur usually arise for the derivatives because the underlying instrument (e.g. a T-Note) is priced using its market price. When Findur calculates delta on the derivative, say a bond total return swap (TRS), the simulation engine shocks the underlying’s market input up by 0.01 (or more accurately, by 1 unit of the configured Delta Shift parameter) and down by the same amount. In so doing, the derivative is repriced and the sensitivity is returned.
User requirements dictate that delta should be the sensitivity to yield, not price, so two mistakes result. The first mistake is that the sensitivity is reported to be in the wrong direction because the yield is inversely related to the price. The second mistake made in Findur is that users expect the sensitivity to a 1 basis point change in the yield, but Findur is shifting the price by a penny on the price.
Put another way, the default configuration returns the derivative’s sensitivity to a $0.01 change in the price of the underlying instead of a 1 basis point change in the underlying’s yield.
Gamma calculations are closely related to Delta calculations so Findur delegates the calculation of Gamma to the function that derives Delta. This is a sensible performant feature. The family of gamma results suffer from the same features and the same flaws as the family of delta results.
What Can Be Done?
At a high level, there are four approaches available to address the problems:
- Reconfigure the underlying bond instrument’s pricing
- Create duplicate bond instrument definitions
- Override the native Findur simulation result via a Result Calculator extension
- Implement a user-defined simulation result
Reconfigure Bond Instrument Pricing to Correct Bond Derivative Greeks
The first category of workaround to Findur’s gaps regarding Greeks on fixed income derivatives is to reconfigure the underlying bond instrument, and specifically its price inputs.
Liquidly-traded bond instruments may be configured in Findur to be marked to market using a market price or a market yield. For example, JGBs and inflation-linked ACGBs are priced using the published yield (or simple yield). These instruments can return reliable Greek results on their derivatives with little or not additional configuration or customization.
Other instruments such as US T-Notes, are marked against a market price input. Findur has support to mark them to market using their yield, which will then resolve issues with Greeks. There are two issues that can arise with this approach.
Firstly, it becomes tedious to setup new bond instrument definitions this way. If the price interface is still receiving a price, the instrument’s price may be imported as the grid point input, and then a formula applied to convert the grid point result to a market yield.
The insertion of a grid point formula is not a standard feature, and will require development effort. The development must be written using the very awkward handling of grid points in OpenJVS, or using Openlink’s premium API, OpenComponents (OC). OC is a licensable feature, so an additional license fee may be required.
The development effort using OC is simple and intuitive. Here is the OC snippet that will insert the price/yield calculation on the bond pricing grid point:
gridpoint
.getDefinitionField(EnumGridPointFieldId.InputFormula)
.setValue("effective=bond_price_to_yield(input,-1);\ninput;")The instruments can be updated using OC as well
leg.setValue(EnumLegFieldId.MarketPriceGptInputEff, "Effective");
leg.setValue(EnumLegFieldId.UnderlyingPXMethod, "Yield to Price");A second issue can arise for derivatives after the underlying bond is reconfigured to price using the yield. Some fixed income derivatives capture their resets from the underlying instrument’s grid point Result field. When the bond’s configuration is changed to price using a market yield, that yield can be caught up in Findur’s native end-of-day fixing process.
For example, a TRS resets on the bond’s price, not its yield. T-Locks can use either price or yield and since the instrument in Findur natively uses the output of the grid point for the reset on the fixing date, it is important to test the fixing operations. As part of a T-Lock implementation we developed an additional customization, a Payment Calculator to handle the resets and payments. As in so many corners of an application such as Findur, one customization often requires additional customizations.
While planning changes to the underlying bond instrument configuration, it is important to consider the requirements for repo and security lending deal entry and collateral management to ensure that changes to the instrument definition do not have an undesirable effect.
While reconfiguring the underlying bond instrument to price using market yield can address unreliable Greeks on the derivatives, several additional customizations might be necessary. For most clients, this is likely to be the best implementation.
Create Duplicate Bond Instrument Definitions
Some users might contemplate the creation of a duplicate bond definition that will be configured for use as the underlying on derivatives. The duplicate bond definition would need to have the correct terms and conditions, would price based on market yield, but the instruments used for outright bond trading, collateral management and repos/security lending, would not be altered.
This is a sloppy workaround and will lead to additional work to maintain duplicate instrument definitions, the risk of using the ‘wrong’ definition for cash security trades and derivatives, possible additional work for compliance, credit, market/operational risk, risk analytics that will not natively net or aggregate exposures to the same instrument, problems if the derivative involves physical delivery into the underlying (which is now a different definition in Findur), reports and interfaces that will need to group on ISIN instead of instrument number, and switching off point-and-click capabilities that detect and prevent the creation of duplicate instruments.
We would strongly advise against the creation of duplicate instrument definitions. Even if there is only a small number of underlying instruments involved in derivatives trading, the maintenance of duplicate definitions, and additional workarounds will be likely to constrain the application’s use in the future.
Override the Native Findur simulation Result via a Result Calculator Extension
We have written previously about Result Calculator extensions. The most direct way to close a gap in native simulation results (‘gap’ is a kind way to describe the problems outlined here!) is to implement a Result Calculator extension.
A Result Calculator allows an organization to override the behavior of a specific result for a specific condition. For example, we have implemented one in the past to fix problems with the core Realized P&L result for inflation-linked bonds.
To fix Greeks on fixed income derivatives, the result calculator plugin intercepts the problematic Greek result, and corrects the behavior. The chief benefit to an implementation that overrides a core result is that it is able to fix behavior that leads to additional downstream problems. When we corrected the Realized P&L result, all reports and accounting results were affected, so no additional customizations or fixes were required. Also in the process, fixing the Realized P&L core result meant that other sim results, Realized P&L MTD, YTD _and _LTD (the family of cumulative month/year/life-to-date results) were fixed with no additional work required.
A result calculator that can fix the Tran Gpt Delta result can address the family of delta results, and even complex dependencies such as P&L Explained. Note that the family of Tran Gpt Delta results includes Tran Gpt Delta By Side, Tran Gpt Delta By Leg and Next Day variants. It is important to plan a Result Calculator implementation that overrides the lowest level variant of these results in order to return consistent and dependable results.
Result Calculator extensions are another advanced function that requires the OC API. There are constraints on which results may be overridden, especially in the class of General results, but the Tran Gpt Delta results may be overridden.
We have struck performance issues that have caused problems, even on low volumes, so may sure any implementation of a result calculator includes performance tests.
User-Defined Simulation Results
As an alternative to result calculators, particularly since they are a licensable feature, many clients rely on user-defined simulation results (UDSRs).
UDSRs are a powerful feature in Findur. If your organization has narrowly focused requirements regarding bond derivative sensitivities, and that is not expected to change, a UDSR may be your fastest, most simple and low-risk solution. However, the creation of a new UDSR to solve a native application deficiency can often lead to additional downstream work.
A UDSR is configured to have dependent results, which ensures that all dependent results have been calculated prior to the UDSR’s execution. The dependent results will be available to the UDSR plugin, which allows the UDSR to retain all of the core features that are reliable, and to override only the components that are unreliable.
For example, an Output Delta UDSR would retain all of the results for interest rate swaps, which can be trusted, remove all of the results for fixed income derivatives, calculate the correct fixed income derivative results, and insert them into the table of results returned to the simulation engine.
When considering the implementation of a UDSR, there are many downstream processing needs to evaluate. We already mentioned P&L Explained, but all reports, data warehouse extracts, desktops, deal entry screens, GUIs and interfaces need to be updated to use the UDSR instead of the equivalent incomplete core Greek result.
The new UDSR can often lead to more than one new UDSR, or amendments to existing UDSRs. Map all of the requirements to consider the scope of the decision’s consequences.
In Summary
As in so much of the advice regarding the implementation and extension of functionality in Findur, there is much to consider up front. In short, it is easy to underestimate the work required to close gaps in Findur’s Greeks for fixed income derivatives.
We have helped clients address these questions before, taking into account their existing portfolio requirements, and future expected needs. Some clients can disregard impacts on P&L Explained, others do not need Findur’s features regarding repos (which remain very powerful). Some only trade fixed income derivatives but none of the underlying bonds.
No matter your needs, we can offer advice and implementation services to address your organization’s needs quickly. The right path involves the fewest complex customizations and will simplify production support and ensure the application remains capable of accommodating future operational needs.
