{"openapi":"3.0.4","info":{"title":"PricingContext","version":"0.0.1"},"paths":{},"components":{"schemas":{"PricingContext":{"type":"object","properties":{"modelRules":{"type":"array","items":{"$ref":"/docs/api/lusid/schemas.json#/components/schemas/VendorModelRule"},"description":"The set of model rules that are available. There may be multiple rules for Vendors, but only one per model-instrument pair.\r\nWhich of these preference sets is used depends upon the model choice selection if specified, or failing that the global default model specification\r\nin the options.","nullable":true},"modelChoice":{"type":"object","additionalProperties":{"$ref":"/docs/api/lusid/schemas.json#/components/schemas/ModelSelection"},"description":"The choice of which model selection (vendor library, pricing model) to use in evaluation of a given instrument type.","nullable":true},"options":{"$ref":"/docs/api/lusid/schemas.json#/components/schemas/PricingOptions"},"resultDataRules":{"type":"array","items":{"$ref":"/docs/api/lusid/schemas.json#/components/schemas/ResultKeyRule"},"description":"Set of rules that control querying of unit results either for direct queries into aggregation or for\r\noverriding intermediate calculations. For example, a dirty price is made up from a clean price and the accrued interest.\r\nOne might consider overriding the accrued interest calculated by a model (perhaps one wants to match an external value or simply disagrees with the\r\ncalculated result) and use that in calculation of the dirty price.","nullable":true},"holdingPricingInfo":{"$ref":"/docs/api/lusid/schemas.json#/components/schemas/HoldingPricingInfo"},"accrualDefinition":{"maxLength":50,"minLength":0,"type":"string","description":"Determines which method to use for the calculation of accrued interest. Defaults to SOD.","nullable":true}},"additionalProperties":false,"description":"Pricing context node. In order to price an instrument a number of configuration parameters are required to determine which\r\n(a) pricing model (ranging from a simple lookup of a market quote/price through to a Monte-Carlo simulation for the behaviour of its cashflows)\r\n(b) vendor library (Lusid internal models or those provided through an external Vendor such as Refinitiv (proprietary) or QuantLib (open source)\r\nare used in the pricing.\r\n\r\nIn conjunction with these there are a number of parameters that govern the behaviour of these models. For example, in pricing an Fx volatility\r\ndependent product such as an Fx option, there are various parameters that affect model behaviour for the smile. In Lusid a distinction is made between\r\nthose which are understood natively and those which are only held for use with a given vendor-model combination. The problem is that, unlike market\r\nquote data, there are few standards around model descriptions. Hence, apparently similar terminology can be mis-leading; for example in SABR models where\r\nthe basic parameters are agreed upon but most practical models have used an approximation with adjustments where the parameters can have wildly different meanings.\r\nTo avoid confusion or mis-behaviour in this area, where parameters are not understood to be interchangeable, they are only settable on a per-library per-model\r\nbasis, essentially as opaque data that will be given to the Vendor library \"verbatim\" but not used with any other.","title":"PricingContext"}}}}