Recipes are our unique, ruleset based approach to valuation, allowing clients to construct waterfalls of instruction sets for pricing and market data at the instrument level. Recipes enable dynamic orchestration of valuation components: model, data, methodology.
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".