By Richard Page & Gareth Evenson
Introduction
This article provides a general analysis of modelling Structured Contracts in Endur and is intended to give an understanding of:
- Contract modelling
- Standard and external valuation models
- Associated capabilities within different versions of Endur.
The scope of the article covers three example deal types:
- Gas Swing
- Gas Storage
- Spark Spread Options
The aim is to gain a high level understanding of how these types of contracts can be modelled in Endur and how various valuation models are used. A particular focus is given on the capabilities of Endur v12/v14 and how new functionality can potentially be used to either value these contracts natively or integrate any existing in-house models.
Trade Classification
Trade Type | Example Trade Scope | Example |
Simple Storage | Virtual Storage, Simple Constraints, Fixed price capacity Storage with a simple structure for a max injection quantity, max withdrawal quantity and max/min inventory, and cost to purchase the storage ‘capacity’, together with injection and withdrawal costs. | NBP virtual storage |
Complex Storage | Physical Storage, Multiple Entitlements, Ratchets, Index Price Capacity Contracts that not only contain maximum injection and withdrawal quantities, but also inventory-based injection and withdrawal quantities, i.e. ratchets, that could be seasonal as well as volumetric. In addition where there are index-priced components such as capacity costs. | Multiple constraint physical storage |
Simple Swing | Flexible volumes with period volume constraints (Daily / Monthly / Yearly). Take-or-pay. | Simple constraints swing contracts |
Complex Swing | Swing trades including Carry Forward, multiple constraint types, covering multiple periods and granularities, formula-based constraints, index pricing, formula-based fees. | Legacy field supply contracts with multiple clauses |
Simple Spark Spread Options | European or Asian options on a basket of Power/Gas | Simple OTC options |
Complex Spark Spread Options | Power plant modelling. Options on a basket of Power/Gas with support for additional constraints such as start-up costs, maximum run times, etc. | Complex options with multiple constraints, e.g. CCGT |
Deal Modelling
Trade Type | Summary | Changes Since V8 |
Simple Storage | This type of contract can be captured using the native Endur functionality, using the COMM-STOR instrument and the limits held as entitlements. | Improvements to data model with increased support for limits capture. |
Complex Storage | This type of contract, cannot be fully captured using the native Endur functionality, but can be supported using native instrument types and custom extensions to the data model These types of storage contract are modelled using COMM-STOR instruments – but with additional considerations relating to index priced capacity and storage entitlements. | Improvements to data model with increased support for limits capture. Addition of extension tools such as user table panels allows for easier extension of the data model |
Simple Swing | This type of contract can be captured using the native Endur functionality, using the COMM-PHYS instrument. | Improvements to data model with increased support for limits capture. |
Complex Swing | This type of contract, cannot be fully captured using the native Endur functionality, but can be supported using native instrument types and custom extensions to the data model, especially for automated updates of Keep Whole. | Improvements to data model with increased support for limits capture. Addition of extension tools such as user table panels allows for easier extension of the data model |
Simple Spark Spread Options | This type of contract can be captured using the native Endur functionality, using the PO-GEN-CALL/PUT instruments. | Limited changes since V8. |
Complex Spark Spread Options | This type of contract could be captured using Endur native functionality, but booking would generally require custom data model extensions and a combination of deals to represent a single contract i.e. Power / Index (gas) + Emissions for a clean spark spread. | Limited changes since V8. |
Deal Modelling Extensions
There are 3 commonly used options for data modelling extensions:
- Transaction info (Tran info) fields. Custom fields added to instrument types within the Endur system, which may hold single values. These can be added without coding and accessed from any standard trade entry screen or trading blotter.
- User tables. These are relational tables added to the Endur database and accessible through the Endur GUI or JVS/OpenComponents API. In V12 and improved support exists for the integration of user tables into desktops and deal entry screens with minimal coding effort.
- OpenComponents based extensions. Enhancements to the Endur data model and GUI screens developed using the OpenComponents library extensions.
The system support for tran info fields and user tables has changed little between Version 8 and 12/14, aside from some new system extensions to better integrate user table extensions into deal skins and trader desktops.
The main enhancements lie with the use of OpenComponents for the development of embedded and stand-alone system extensions.
Native Endur Pricing Models
Trade Type | Summary and conclusions | Changes Since V8 |
Simple Storage | Endur Optimized storage model available as beta in V12 and as part of standard build in V14*. Will support pricing and risk for simple storage transactions. Full documentation of the model is available from OpenLink, and model is also supplied as XL plug-in for testing and validation. | New model available. |
Complex Storage | No native model support. New storage model may support some of the less complex storage deals. | No change. |
Simple Swing | Endur Optimized swing model available as beta in V12 and as part of standard build in V14*. Will support pricing and risk for simple swing transactions. Model is also supplied as XL plug-in for testing and validation. | New model available. |
Complex Swing | No native model support. New swing model may support some of the less complex storage deals. | No change. |
Simple Spark Spread Options | Full set of spread option models available including Vorst Lognormal, lognormal, quasi and standard monte-carlo. | No change. |
Complex Spark Spread Options | No native model support. | No change. |
* Licensable feature
External Pricing Model Integration
- Pre-Version 9 external model integration was performed via a set of C libraries. The functionality provided by these libraries to interact and manage pricing and risk scenarios was limited and integration was difficult. There was very limited ability to pass model derived Greeks back to the Endur application.
- The new OpenComponents based Endur extensions delivered with version 9 and above provide extensive support for external model integration, market data management, GUI development and other functions across the Endur application. With OpenComponents external model integration is a much simpler process and has been successfully executed by other clients, including BP for storage and swing contracts.
- The new external pricing model (EPM) interface provides a much simpler framework for interaction with external models, and also provides the ability for model code to interact with simulations to better manage the valuation process. For example the model interface now provides some state information as to what process / result is being executed, so the external library is able to both identify what Greeks have been requested and what result or scenario is currently being processed.
- With the new EPM interface it is possible to either utilise Endur’s standard result calculation process of perturbation of market data, or to take model derived Greeks and return these to the Endur simulation process so that they can be integrated with Endur’s standard results derived from other deals.
- A number of limitations still exists with this interface, with the main constraint probably being that Endur core code is single threaded and therefore interaction with the external libraries is also best limited to a non-threaded approach. This may place some performance constraints for calculation of Greeks on more comple§x trades and models:
- Integration of external models with extended execution times will require configuration of the Endur system to support some parallelisation of the calls to the trade models. This is done generally via the implementation of trade splitting over multiple batch or revaluation services. There is native Endur support for this type of trade splitting.
- Although Endur does supply some grid services, it should be assumed that the Endur system will not natively support any parallelisation or optimisation of the execution of the external model.
- A number of clients have implemented external models using this approach and have integrated models for Storage and Swing.
Conclusions
System Function | Simple Storage | Complex Storage | Simple Swing | Complex Swing | Simple Spark Spread Options | Complex Spark Spread Options | ||
1 | Deal Data Modelling and Trade Capture | Can be modelled and captured natively in Endur. | Improved support in all versions, but will generally require the combination of native booking + data model extensions. | Can be modelled and captured natively in Endur | Improved support in all versions, but will generally require the combination of native booking + data model extensions. | Can be modelled and captured natively in Endur | Limited native support. Will require combination of custom extensions and multiple trade bookings. | |
Native support | Custom Extensions Required | Native support | Custom Extensions Required | Native support | Custom Extensions and multiple trades required | |||
2 | Trade Lifecycle Management | Native trade lifecycle support, but may require customization for automation of some processes such as volume management and notification. | Native trade lifecycle support – but integration of custom attributes would require customization of payment formulae or addition of JVS/OpenComponents code. | Standard system functionality will support trade lifecycle management, but may require customization for automation of some processes such as volume management and notification. | System will generally support lifecycle management- but integration of custom attributes would require customization of payment formulae or addition of JVS/OpenComponents code. | Native support for trade lifecycle management. | Limited native support for lifecycle management; will generally require customization for some processes, depending on trade complexity. | |
Custom Extensions Required | Custom Extensions Required | Custom Extensions Required | Custom Extensions Required | Native support | Custom Extensions Required | |||
3 | Native Pricing – Valuation and Risk – V12 | No standard models for storage other than simple discounting (intrinsic value of inventory). Beta model available for storage valuation, not fully supported. | No standard models for storage other than simple discounting (intrinsic value of inventory). | Simple discounting giving intrinsic value only. | Simple discounting giving intrinsic value only. | Standard spread option pricing models supported and may be used, based on trade booking approach and complexity. | Simple discounting giving intrinsic value only. | |
Beta Model only | No support | No support | No support | Native models available, but would need validation | No support | |||
4 | Native Pricing – Valuation and Risk – V14 | Standard Gas Storage optimization model available. | No native Endur model support | Standard Swing optimization model available. | No native Endur model support | Standard spread option pricing models supported and may be used, based on trade booking approach and complexity. | No native Endur model support | |
Native models available, but would need validation | No native support | Native models available, but would need validation | No native support | Native models available, but would need validation | No native support | |||
5 | External Pricing – Valuation and Risk | External models can be integrated via OpenComponents extensions. | External models can be integrated via OpenComponents extensions. | |||||
Model PV and Greeks can be returned and injected into native Endur result sets, and other functional such as optimized volume schedule updates can be implemented. | Model PV and Greeks can be returned and injected into native Endur result sets. | |||||||
Custom Extensions | Custom Extensions. If trade is booked as multiple deals then further constraints on external valuation may exist. | |||||||
6 | PNL and PNL Explained | Supported for all trade types through the use of Endur optimization models or external models, if Greeks are injected back into standard Endur result sets. | ||||||
Enhancements to P&L explained processes may be required if non-standard attributes are included. | ||||||||
May Require Custom Extensions, requires PNL/Greeks to be integrated back into Endur native results |