LUSID has been designed to maximise flexibility for its users.

Nowhere is this more evident than in the use of recipes. Recipes are a set of rules that infer specified LUSID system behaviour. The benefits include:

  1. Governance - the definition of system behaviour in one place
  2. Deterministic behaviour e.g. a “results key” for the valuations engine

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.


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