When performing any financial calculation, LUSID allows for the model, the market data and the risk measures to be separated from the instrument and transaction detail using recipes. This article details how recipes are used in this context.
From the modelling perspective, this allows the user to specify e.g. which model to use for discounting forward cashflows, how to value optionality and how to model the probability of default.
From the market data perspective, the user can choose e.g. the data source for FX rates, the discount curve for a USD swap, or which exchange to source for equity prices.
From the risk measure perspective, the result set can be configured e.g. to report in domestic currencies, to display the risk in spot or forward space, or to specify the base in FX forwards and swaps.
The recipe is the method by which this information can be specified and used to control the analytics engine within LUSID.
What are the benefits of recipes?
Suppose that a portfolio manager or bank has separate teams calculating FX and interest rate risk. It is desirable that pricing should be consistent across the firm in these asset classes. Logically, this implies one specialist per asset class should be responsible for defining and maintaining the rules around pricing. LUSID can handle this specialisation by creating an ‘official’ recipe to configure the model, the market data and the risk measures. Once created, other users can access this ruleset and either use it as is, or combine it with additional rules or pricing configuration on top.
Separately, a control function might wish to look at the ways in which pricing differs between teams; they could do so by inheriting a recipe from each desk and exploring the differences in each. They can then easily override certain rules for report-based valuation or scenario analysis and bring in other models from the organisation or even externally if necessary for price testing.
Essentially a LUSID recipe allows for the specialist knowledge necessary for the operation and understanding of complex financial instruments to be encapsulated in a single document to act as the basis for controlled adaptation through the inheritance of master recipes.
How do I create a recipe?
A recipe can be given to LUSID in various ways. It can be created externally and passed in directly as a DTO to an aggregation or similar request. It can also be created and then stored in the recipe store for use at run time.
Why would I want to store recipes?
By storing a recipe, it becomes available to all users at a client who have permissions to see it. It can become, if desired, a way to ensure everyone prices from the same set of rules, or make clear instances where that is not the case. For audit purposes, it becomes easier to control and report when changes in pricing occurred and who made them.
Storage also allows for categorisation and versioning. Instead of having to worry about which set of preferences were used to generate a result set, one can refer to a named recipe that can be tied to the function, e.g. "Desk1-closing-exotics" or "market-risk-CCAR".