Changing pricing models for instrument types in a recipe

A recipe has a pricing section that we strongly recommend you use to change the default pricing models. Note the following:

• Most instrument types support several models with different capabilities and market data requirements. The default model is typically no longer the recommended model as models have developed over time.

• You can conditionally select different pricing models for the same instrument type, so that (for example) European options are priced using BlackScholes and American options using BjerksundStensland1993.

• You cannot change the pricing model for equities. Only SimpleStatic is available.

Note: The combination of instrument type and pricing model impacts the quantity and quality of market data required. Find out more about this.

For each instrument type whose pricing model you wish to change, specify a vendor model rule in the modelRules array of the pricing section of your recipe. Consider the following example, of three vendor model rules to change the default models for bonds, FxForwards and equity options (all others are left unchanged):

"pricing": {
  "modelRules": [
    {
      "supplier": "Lusid",
      "modelName": "Discounting",
      "instrumentType": "Bond"
    },
    {
      "supplier": "Lusid",
      "modelName": "Discounting",
      "instrumentType": "FxForward",
      "modelOptions": {
        "modelOptionsType": "FxForwardModelOptions",
        "forwardRateObservableType": "FxForwardCurve",
        "discountingMethod": "ConstantTimeValueOfMoney",
        "convertToReportCcy": true
      }
    },
    {
      "supplier": "Lusid",
      "modelName": "BlackScholes",
      "instrumentType": "EquityOption",
      "modelOptions": {
        "modelOptionsType": "EquityModelOptions",
        "equityForwardProjectionType": "ForwardProjectedFromRatesCurve"
      }
    }
  ],
  ...
},
...

In this example:

• The first rule values simple fixed-rate bonds using Discounting.

• The second rule values FX forwards using Discounting, with model options that read the forward rate from an FX forward curve, don't discount, and value directly in the report currency.

• The third rule values equity options using BlackScholes, with model options that project the forward price of the underlying from the rates curve.

For information on all the fields and allowed values in a vendor model rule, examine the VendorModelRule schema. The following table summarises key fields:

Note: LUSID doesn't check whether a pricing model supports an instrument type when you save a recipe. If it doesn't, valuation fails with an error such as "Failed creating pricing model… does not support instrument… of type BondForward". To find out which models an instrument supports, see What pricing models can I use in my valuation?

Selecting different pricing models for the same instrument type

You can conditionally select pricing models based on:

• Properties (custom, system or derived) in the Portfolio domain, for example Portfolio/People/Manager.

• Properties (custom, system or derived) in the Instrument domain, for example Instrument/FX/DataProvider.

• Features for OTC instruments, for example Instrument/Features/ExerciseType.

For example, you might want to specify that:

• American FX option contracts are valued using the BjerksundStensland1993 pricing model.

• European FX option contracts sourced from Bloomberg are valued using the BlackScholes pricing model.

• European FX option contracts sourced from UBS are valued using the Discounting pricing model.

To do this, specify multiple vendor model rules for the same instrument type and distinguish them using the addressKeyFilters field:

• The left field must reference the 3 stage key of either a property or a feature. In the example below, Instrument/FX/DataProvider is a property added to instruments of type FxOption to record the original data provider, while Instrument/Features/ExerciseType is a feature key referencing one of the available exercise types for FX option contracts in LUSID.

• The operator field must either be eq or neq.

• The right field must be a string value on which to match, with a resultValueType of ResultValueString. Note this means only properties with an underlying data type of String are currently supported.

Note: Vendor model rules are processed in the order they are specified in a recipe. The first matching rule found is used. Instruments that do not match any rules fall back to using the default pricing model for the instrument type, which is SimpleStatic for FX option contracts.

"pricing": {
"modelRules": [{
  "supplier": "Lusid",
  "instrumentType": "FxOption",
  "addressKeyFilters": [{
    "left": "Instrument/Features/ExerciseType",
    "operator": "eq",
    "right": {
      "value": "American",
      "resultValueType": "ResultValueString"
    }
  }],
  "modelName": "BjerksundStensland1993"
},
{
  "supplier": "Lusid",
  "instrumentType": "FxOption",
  "addressKeyFilters": [{
    "left": "Instrument/Features/ExerciseType",
    "operator": "eq",
    "right": {
      "value": "European",
      "resultValueType": "ResultValueString"
    }
  },
  {
    "left": "Instrument/FX/DataProvider",
    "operator": "eq",
    "right": {
      "value": "Bloomberg",
      "resultValueType": "ResultValueString"
    }
  }],
  "modelName": "BlackScholes"
},
{
  "supplier": "Lusid",
  "instrumentType": "FxOption",
  "addressKeyFilters": [{
    "left": "Instrument/Features/ExerciseType",
    "operator": "eq",
    "right": {
      "value": "European",
      "resultValueType": "ResultValueString"
    }
  },
  {
    "left": "Instrument/FX/DataProvider",
    "operator": "eq",
    "right": {
      "value": "UBS",
     "resultValueType": "ResultValueString"
    }
  }],
  "modelName": "Discounting"
}],
...

For a more detailed demonstration of conditional pricing model selection, examine this Jupyter Notebook.