What is a LUSID recipe and how is it used?

Understand the function of recipes in LUSID and how you can use them to configure the behaviour of system sub-systems.

Introduction

LUSID has been designed to maximise user configurable functionality. Building in a high degree of flexibility ensures that LUSID implementations will better meet client requirements.

This high degree of configurability has been implemented using Recipes. Recipes are a set of rules that infer specified LUSID system behaviour. The benefits include:

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

Recipes support a high degree of user configurability and will expose a great deal of system complexity to users. To ensure that the Recipes mechanism is usable, the implementation and client deployment of Recipes will “package” the complexity and provide diagnostic tools to allow users to understand the behaviour Recipes both at implementation and during ongoing operations.

Key Concepts

Recipes are defined for each LUSID sub-systems and can define 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 will operate independently of each other and can be combined into recipe books, a “super recipe” that contains multiple complete recipes. Invocations of recipes will write the resolved recipe to a manifest to support auditing and logging. Recipes specifying e.g. market data substitution rules will 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 will be used in the following contexts:

  • Valuation engine requests (recipe 1..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 (recipe 1)
    To specify the basis for a market data request by a system using LUSID as the master price repository
  • IBOR holdings request (recipe 2)
    To specify the holdings basis for a positions request by a system using LUSID as a master positions store
  • Client reporting (recipe 5)
    To specify the classification and aggregation of reporting results