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.

Key Concepts

Recipes are defined for each LUSID sub-systems, 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 from 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: The market data key pattern for the rule, can be set by using a dot separated string. (For example, “Equity.ClientInternal*” will search for all quotes using the ClientInternal identifier for instruments falling under the Equity key.)
  • Provider/Supplier: The supplier for the required market data (e.g. “Lusid”)
  • Data Scope: Specifies under which scope the rule will seek to 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 rate: Boolean for whether or not valuation will seek to infer an FX rate from an inverse when a direct option is not available. (e.g. use GBPUSD if USDGBP not found, seek for a bridge when provided GBp or GBx quotes.) 

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