Endur – Structured Gas Contract Modelling

Endur – Structured Gas Contract Modelling

 By Phil Walsh



1.Complex Price Formulae

Since the addition of formula functions, for example to assess different volume types (e.g. nominated vs allocated) within a pricing formula, the instances of Endur not being able to support structured gas contract’s pricing formulae are fairly rare. As such, the main areas for consideration within the pricing structure of the contracts are more in relation to the modelling approaches taken, given that there are a variety of options and some lower level critique of the management of pricing formulae. Specific examples are:


  • Averaging methods

    Lagged average pricing definitions, termed Projection Methods in Endur – and their association with contract structures – can be implemented in various ways. A good example, here, is where the price average is multi-step, e.g. averages of daily published prices then averaged over several monthly periods to determine the final price for a particular index.


    Implementation options in this case, and high level considerations, include:


  1. Separating the averaging steps between the pricing index, to calculate the first step of the average, and a single averaging method to average the monthly prices. With this approach, the index needs to be carefully constructed in order to calculate exposures correctly and efficiently.
  2. Constructing individual averaging methods for each monthly average. This approach has the disadvantage of increasing the, i.e. an averaging method per month, rather than single averaging method, and requiring the pricing formula to calculate the final average, rather than being pre-computed by a single averaging method.
  3. Utilising newer Projection Method features to calculate both averaging steps within a single averaging method. Here, the features are less tried and tested, with issues around supporting inherent FX conversion methods being one concern.


  • FX Conversion

    Whilst the FX conversion methods within the contract structures are reasonably flexible, there can be various reasons for applying FX conversion logic within the index referenced by the contract rather than applying the FX conversion within the contract structure. These cases require careful consideration in order to ensure exposures are generated in the appropriate currency (see also the later sub-section on P&L explained).



  • Judicious use of free-hand formula editor

    A more obvious implementation recommendation is to ensure that the free-hand formula editor is not used in cases where not necessary, i.e. where there are user interface facilities which can be utilised to perform the same calculation steps. For example:


  1. Exposing fixed parameters rather than hard-coding within the pricing formula.
  2. Performing FX conversion utilising standard contract construction methods, rather attempting to replicate within the formula editor.
  3. Performing individual index price rounding utilising standard contract construction methods, rather than within the formula editor.
  4. Applying explicit price caps and floors using user interface settings, rather than within the formula.


  • Formula libraries

    One reasonably common criticism of the application, with regards to complex pricing formulae, is how the library of formulae can be managed.


  1. Shared pricing formulae, so that updating a single pricing formula will propagate the changes to the transactions referencing the formula, whereas each transaction would require the common formula to be amended independently. However, where there is a component of a common formula that is required to be updated periodically (such as a ‘fixed’ parameter that is re-negotiated periodically) the component can be modelled as a pseudo price index.
  2. Multi-layered formulae, or formula components, where a single transaction can be constructed by combining multiple, typical formula clauses. To some degree this can be supported by managing the formula components as individual price indices, but this can lead to a dis-jointed configuration of the application and requires careful construction of the price indices in order to ensure price exposures are calculated accurately and efficiently.
  3. Partitioning formula templates for security segregation.


2. Constraints

Contract constraints are modelled through a variety of system mechanisms:

  • Volume Constraints – for defining minimum and maximum volumes per day, month, season, year etc.


  • Volume Constraint ‘implementation packages’ – where volume constraints cannot be modelled through the above facility, it is possible to augment the application with additional volumetric conditions through system extension facilities. For example, the core Volume Constraints capability didn’t support conditions around carry forward and make-up gas, but could be implemented as system extensions. Where such conditions are typical contract modelling requirements, but have not been enabled as core Volume Constraints application, they may be available alternatively as an ‘implementation package’ where the support for the package is managed by the local Openlink client services function, rather than Openlink’s core product centre.


  • ‘Keep-Whole’ – for take-or-pay volume pricing conditions.


  • Contract Entitlements – this is specifically for storage facility injection, withdrawal and space contractual entitlements.

Key considerations for implementing contract volumetric constraints therefore are:

  • Gaining clarity on which mechanism is being used for each aspect of modelling constraints.
  • Where several of the above mechanisms are being utilised, also analysing any necessary interaction between the mechanisms, as they are largely independent frameworks.
  • Where the volume constraints are managed through an ‘implementation package’, understanding any additional licence and support implications.




3. Contract Valuation and Risk Management

Endur is currently only utilised to generate intrinsic contract valuations, for structured gas contracts, other than certain cases where storage pricing models have been integrated into instances of the application. As such, this section mainly provides pointers in relation to intrinsic valuations of contracts and associated risk measures, but also provides some pointers around how extrinsic contract valuations could be enabled within the application.


Intrinsic Valuations



Intrinsic valuations will naturally feed into the standard mark-to-market and P&L results. In addition, P&L explained results have also been utilised to explain the changes in P&L caused by index price, FX rate, interest rate and volume usage changes. Key considerations here are:

  • Referring back to the earlier described case, where FX conversion is applied at the index level, rather than within the contract structure, requires careful index construction to ensure the P&L explanation is accurately and efficiently divided between changes in the commodity price and FX rate.


  • Referring back to the earlier described case of multi-step index price averaging, again indices need to be carefully constructed in order to ensure P&L movements are explained as accurately as possible, depending upon which implementation option is chosen.


  • For P&L explanations due to contract volume usage changes, this is a newer system capability and initial implementation issues should largely have been addressed, but it is worth noting that prior implementations have required ‘custom’ coded solutions to address issues where the core calculation has generated inaccurate results.


Index price exposures

  • A natural implication of calculating intrinsic values is that, not only will the calculated index price exposures only reflect the intrinsic valuation, but that these calculations will be largely unintuitive when the current index price is equal, or very close, to a step change in the pricing formula logic.


  • As with the P&L explained points, for the earlier described cases of FX conversion and multi-step averaging, careful index construction is required to generate correct results efficiently.


Risk calculations and optimsation

  • Risk calculations – The intrinsic value will be incorporated into Value-at-Risk measures, although simulation based, rather than parametric , methods are advised given the latter’s disadvantage particularly where current index prices result in the contract lying at step change in the price formula.
  • Contract volume optimisation



4. Extrinsic Valuations

As stated earlier, Endur is not currently utilised for calculating extrinsic valuations for structured gas contracts. This section provides some considerations if this were to be considered as part of the project scope.

POC work has been undertaken to demonstrate the feasibility of supporting extrinsic valuations, where the implications for contract modelling are important:

There are two ways to model the contracts:

  • Modelling as a single contract, which is how the contracts are typically modelled, and enable an External Pricing Model to perform the entire contract valuation. In this case, the External Pricing Model would need to understand the free-form formula text embedded within the pricing formula which is complex to develop and is likely to lead to slow computation times.


  • Separately book the component option-equivalents where there are price caps/floors, only utilising the pricing formula for the linear pay-off elements of the contract. Standard pricing models can be used to value the individual option components and so calculation time is dependent on standard models only; or external pricing models can be developed to value each option component, which is much easier to achieve, given that free-hand formula text would not need to be parsed. Financial risk results such as VaR and P&L explained would naturally take account of the extrinsic valuation.


However, the downsides of the latter approach include:

  • Deal booking becomes more disjointed and probably more complex for users.
  • Where volumes are updated periodically for a contract, the updated volumes would need to be passed to each relevant component.
  • It is likely that both the single contract and individual components would need to be managed in conjunction (in separate portfolios), as the latter may make settlement process more cumbersome.
  • There may be non-linear formula components which can’t be translated into suitable option components, such as the temperature related price impacts.
  • The skill-set for implementing the extrinsic valuation approach is scarce.


5. Settlement

Validation of the contract modelling features should prove that the base contract settlement amounts can be calculated accurately. As such, the key considerations for processing settlements to invoices are mainly as follows:

  • Are provisional settlement amounts to be invoiced? If so can this process be managed effectively through Endur?
  • Can the taxation amounts be calculated accurately within Endur?
  • Is the invoice generation process as seamless as in external invoicing solutions?
  • Are there additional minor, settlement amounts or adjustments to be processed at the point of invoice generation/verification? If so, are these additional amounts more appropriately managed within Endur or in an external invoicing solution?


6. Contract Negotiation Period

Endur is not used to represent a structured contract throughout its life-cycle pre-signing, other than processing to a Pending status to assess financial and physical position impact prior to contract signing.

Some analysis of supporting further requirements for representing contracts prior to signing has taken place, including:

  • Leveraging recent developments for supporting term oil contracts where detailed, multiple contractual clauses need to be accessible by the application for generating appropriate contractual documentation.
  • Addressing insufficient contract life-cycle status management, for the pre-signing period, by utilising TPM’s capabilities for supporting additional transaction life-cycle modelling requirements and segregation of duties.


7. General implementation considerations/issues

In addition to the above specific considerations, some general implementation considerations include:

  • Rather than implementing the contracts individually, break the contracts down to the key constituent parts: indices, averaging (projection) methods, FX conversion, constraints, fees, price formulae etc. and group by these constituents for a more efficient, ‘synergised’, implementation approach.
  • Consider splitting very long-term contracts into separate individual contract ‘chunks’, e.g. 5 yearly chunks, where possible. This is to ensure that un-necessary historical periods are not continually reloaded within revaluations.
  • Reconciliation – ensure from the outset that there is a comprehensive mechanism for reconciling the calculated outputs of Endur.
  • If Endur will not be the sole repository of the contracts, synchronisation of contract definitions is a key consideration.
  • Performance – sizing the end solution, particularly to ensure that end-of-day/over-night batch calculations can be performed within required timescales, is a key consideration from the outset, as is designing the workflow for end-of-day/over-night processes.


Have your say:

Download PDF version

This field is for validation purposes and should be left unchanged.