LUSID has been designed to maximise flexibility for its users.

Nowhere is this more evident than in recipes, which are a set of instructions for the valuation engine to determine how pricing will be conducted as well as what data will be used in the the process. 

Recipes support a high degree of user configurability and expose a great deal of system complexity to users. To ensure that the recipes mechanism is usable, the implementation and client deployment 'packages' the complexity and provides diagnostic tools to allow users to understand the behaviour of each recipe at implementation and during ongoing operations.

Note the following:

  • LUSID has a very simple default recipe that it may be suitable to use for basic quantity * price valuations. It requires prices in the Quotes store to be uploaded in a certain way. See this Jupyter Notebook for details and an example.
  • It may be possible for LUSID to automatically generate a recipe for you.

Key Concepts

Recipes are defined for each LUSID sub-system, defining two types of behaviour:

  • Flags – system parameters that are passed to the sub-system
  • Substitution rules – used by e.g. the market data and reference data mastering systems.

Recipes for each sub-system operate independently of each other and can be combined into recipe books, a “super recipe” that contains multiple complete recipes. Invocations of recipes write the resolved recipe to a manifest to support auditing and logging. Recipes specifying, for example, market data substitution rules support data quality meta-data e.g. RAG status.

Recipes for LUSID Systems

Recipes are used to define the behaviour of the following LUSID sub-systems:

  1. Market data: How the value of a market data price <item/element> is derived based on data source, quality and hierarchy rules. 
  2. Holdings: How a set of holdings is constructed by the Movements Engine from transactions and corporate actions in the Event Register.
  3. Pricing (Analytics): How a unitised PV (and other results) are to be calculated based on the engine to be used, the library or model from that engine and the model options/parameters. See How are recipes used in performing financial calculations?
  4. Reference data: The classification scheme to be used.
  5. Results/Aggregation: How the results of the analytics calculations are aggregated and broken out, and where the results are to be stored.

Key components of a Recipe:

  1. Market context: How market data is resolved from the quotes store, specifying where data is loaded from and which source takes precedence over another.  
  2. Pricing context: How valuation will be conducted, allowing for the selection of a pricing model ranging from simple lookup to more nuanced methodologies. 

Market Context

Market Data Key Rules: Allow for user specified market rules, that are provided as a list/array and processed in order.

  • Key: A dot-separated string that defines a pattern for looking up market data:
    To look up......stored in the......use a Key with the syntaxExamples
    QuotesLUSID Quote storeQuote.<IdentifierType>.<Identifier>
    • Quote.RIC.* to look up quotes by RIC
    • Quote.LusidInstrumentId.* to look up quotes by LUID
    • Quote.Isin.GB0031348658 to look up quotes by a particular ISIN

    Note: Quote.*.* does not look up quotes by any identifier.

    FX ratesFx.<FgnCcy>.<DomCcy>
    • Fx.USD.GBP to look up USD/GBP rates
    • Fx.*.* to look up any FX rate
    Discounting curvesLUSID Complex Market Data storeRates.<Currency>.<Currency>OIS
    • Rates.USD.USDOIS to look up USD discounting curves
    • Rates.*.* to look up any discounting curve
    Interest rate projection curvesRates.<Currency>.<Tenor>.<Index>
    • Rates.GBP.1Y.LIBOR to look up the 1 year GBP to LIBOR rate
    • Rates.*.*.* to look up any interest rate projection curve
    Equity volatility surfacesEquityVol.<RIC>.<Currency>.<L-or-LN>
    • EquityVol.AAPL.USD.LN to look up a log-normal volatility surface for Apple
    • EquityVol.*.*.* to look up any equity volatility surface
    FX volatility surfacesFxVol.<Currency1>.<Currency2>.<L-or-LN>
    • FxVol.GBP.USD.L to look up a normal GBP/USD volatility surface
    • FxVol.*.*.* to look up any FX volatility surface
    Interest rate volatility surfacesIrVol.<Currency>.<L-or-LN>
    • IrVol.USD.LN to look up a log-normal USD volatility surface
    • IrVol.*.* to look up any interest rate volatility surface
    Credit curvesCredit.<REDCode>.<Currency>.<Seniority>.<RestructuringClause>
    • Credit.FF667M.USD.SNR.MR to lookup a senior CDS with modified restructuring
    • Credit.*.*.*.* to lookup any credit curve
  • Provider/Supplier: The supplier for the required market data (e.g. “Lusid”)
  • Data Scope: Specifies which scope the rule will use for resolving market data from the quotes store. (Should match scope of provided quotes.)
  • Quote Type: Specifies the type of quote used. The available values are:  Price, Spread, Rate, LogNormalVol, NormalVol, ParSpread, IsdaSpread, Upfront
  • Field: The field for a given price such as mid, bid or ask. Notice that the use of field is case-sensitive and needs to match that of provided quotes.
  • Quote Interval: Shorthand for the time interval for which pricing data will be looked up in effectiveAt space.  The interval is specified as a dot separated string with a start and end period, e.g. 5D.0D to look back 5D starting today (0 days ago).
  • Price Source: The source of the quote for a given provider/supplier of market data, where relevant. (e.g. the exchange or bank that provided the quote)

Market options: allows specification over how market resolution behaves.

  • Default Supplier: Set the default value for the market data provider/supplier
  • Default Scope: Set the default value for the marked data scope
  • Default Instrument Code Type: Set the default identifier type by which quotes will be looked up in the quotes store
  • Attempt to infer missing FX: Boolean for whether or not valuation will seek to infer an FX rate from an inverse when a direct option is not provided, for example using GBPUSD if USDGBP is not available. Can also act as a 'bridge', for example using GBPEUR and multiplying by 0.01 if GBpEUR is not available.
  • Calendar scope: The scope in which holiday calendars such as Copp Clark are stored. 

Pricing Context

Model Rules: Allow for user specified model rules, that are provided as a list/array and processed in order.

  • Provider/Supplier: Specify the model provider (e.g. “Lusid”)
  • Model name: Name of the model or vendor library used (e.g. “SimpleStatic”, “Discounting”)
  • Instrument Type: The instrument type to which the rule is applied (e.g. “Equity”, “InterestRateSwap”, “Bond”, etc.)
  • Parameters: Other opaque model parameters, and empty dictionary can be provided if none are specified.

Model Options: Allow for user specified options controlling default behaviour of the pricing engine, see below for some of the commonly used parameters (see API docs for full list of parameters available for configuration).

  • Model Selection: Name of the model or vendor library used (e.g. “SimpleStatic”, “Discounting”)
  • Allow Partially Successful Evaluation: If set to True then a failure/exception doesn’t cause the entire request to fail. Results will be returned where successful, and annotated elsewhere.

Result Data Rules: Set of rules that control querying of unit results when seeking to override certain elements in intermediate calculation. For example, one might consider overriding the accrued interest calculated by a model and use that in calculation of the dirty price.

  • Resource Key: The result data key identifying the rule's targeted metric (what is the rule applied for?)
  • Supplier: The result resource supplier (where is the data coming from?)
  • Market Data Scope: The market data scope in which the results are found.
  • Document Code: Code that defines which document to use. 
  • Quote Interval: Shorthand for the time interval for which pricing data will be looked up in effectiveAt space.  The interval is specified as a dot separated string with a start and end period, e.g. 5D.0D to look back 5D starting today (0 days ago).

Use Cases for Recipes

Recipes are used in the following contexts:

  • Valuation engine requests (1 to 5 above)
    A recipe book combining 5 recipes (market data, holdings, pricing, reference data and results) used to define the request configuration
  • Market data requests (1)
    To specify the basis for a market data request by a system using LUSID as the master price repository
  • IBOR holdings request (2)
    To specify the holdings basis for a positions request by a system using LUSID as a master positions store
  • Client reporting (5)
    To specify the classification and aggregation of reporting results