by Richard Knight

Summary

Occasionally COMM-TRANS deals can show index delta values attributed the wrong deal side in the Tran Gpt Delta by Leg result.  Is this expected behaviour or a defect?  Is there a way to force Endur to create the delta on the a side that’s consistent with the deal booking screen ie side 1 for Zelzate and side 3 for ZBR?

Endur uses the finite difference method to calculate delta and gamma results by measuring the change in MTM for each side by bumping the grid point values up and down. Therefore it’s worth reviewing how MTM is calculated for Transport Deals using 0/1 Discounting model.

0/1 Discounting Model

Transport deals have delivery (to) and receipt(from) legs and are used to capture forecast and actual gas flows between two gas network points. In the absence of forecast profiles generated by an optimisation system it is common to overlay the transport deal’s forward schedule with net available capacity ( See KWA Article “European Cross Border Gas Capacity and Flow” for further discussion on the modelling transportation capacity and flows ).

So in this scenario the past schedule on the transport deal shows actual flows, the forward schedule shows available capacity and typically the operating window of today and three working days ahead is updated with nominated flows.

The 0/1 Discounting model calculates the intrinsic present value (at daily/hourly granularity) of each deal profile and the total value of the deal is the sum of all the profile values plus any fees. Using the 0/1 Discounting model means that if a given profile is out of the money then the net present for that profile will be zero. If the profile is in the money then it will behave the same as a Discounting model, or expressed as a formula:

Intrinsic PV = Max [ 0, PV_{delivery leg} – PV_{receipt leg} – PV_{variabletransportcosts}]

For Gas Transport deals using 0/1 Discounting model there are two ways to view the net pv for every profile:

i) Either as a combined value all reported on deal leg 4 (the financial side of the receipt leg) or ii) as the separate value associated with each delivery and receipt leg. View i) or ii) is controlled by 0/1 Discounting Pricing Model attribute “Comm Trans Value By Side”, No for i) and Yes for ii)

If “Comm Trans Value By Side” = Yes then the net pv will be reported each deal leg with each leg showing its contribution to the pv, though, based on the above formula, a non-zero net PV will only show on each leg if the profile is in the money; if it is out of the money then each leg will show zero pv for that profile.

Delta

For a transport deal between network points with a small forward price differential, some of the deal profiles can be at the money ( or only slightly in/out of the money). In these cases, when the grid points on the forward curve of each deal leg are independently bumped up and down ( by the delta shift configured on each grid point) the profile can in effect change to be in/out the money, so the Net PV > 0 which causes each side to show its respective non – zero contribution towards the Net PV.

To look at this in more detail let’s consider the following scenario:

Transport Deal

Pricing Detail

In the case where the deal legs are in different currencies, to calculate a net pv the system converts the ‘to’ leg price to ‘from’ leg currency at the prevailing fx spot rate. Therefore, to calculate a net pv for the profile, the Zebrugge price is converted as follows:

Zebrugge EUR/MWh = Zebrugge GBP/Therm * FX_EUR/GBP * Conv_Therm/MWh

= 0.5842 * 1.2262 * 34.1214245

= 24.4435

Delta Calculations

The system will report delta as follows – note that deal leg 1 is the ‘from Zelzate’ leg and leg 3 the ‘to Zebrugge’

So why do I see Zebrugge exposure attributed to the receipt leg for an Index Linked deal to the delivery leg ?

First let’s compare the to/from leg prices as they are bumped during the calculations:

With Zebrugge price held steady and bumping Zelzate, the profile remains in the money

However, with Zelzate held steady the profile goes out of the money when Zebrugge is bumped down.

Now let’s see how this affects the delta attributed to each deal leg:

Endur Delta = ( PV_up – PV_down ) / 2

The Zelzate (leg 1) intrinsic of – 49.06032 is calculated as follows:

Leg 1_intrinsic = (59,960.19 – 59,944.92) – (59,960.19 – 59,895.86) = – 49.06032 eur

Because the profile remains in the money, effectively the Zebrugge.GBP exposure drops out leaving delta exposure only on Zelzate index attributable to leg 1:

Leg 1 Delta_Zelzate
= – 49.06032 * DF / 2

= –24.4607 (eur)

Now looking at the Zebrugge leg 3 intrinsic, the profile intrinsic goes out of the money on the price bump down leaving pv exposure to Zebrugge.GBP attributed to both leg 1 and 3:

Leg 3 Delta_Zebrugge = ( Leg 3_intrinsic / FX_EUR/GBP )* DF / 2

= ( 60,062.83 / 1.2262) *
0.9954757 /2

= 24,380.10 (gbp)

Leg 1 Delta_Zebrugge = Leg 1_intrinsic / FX_EUR/GBP * DF / 2

= ( 59,920.39 / 1.2262) *
0.9954757 /2

= 24,363.61 (gbp)

So in summary, the on/off nature of the pv calculation of the 0/1 Discounting pricing model is the cause of a large PVup value being subtracted by a zero PVdown, to generate the erroneous delta.

The 0/1 Discounting pricing model is correctly generating a zero PV for deal, leg, profile after index, grid-point is shocked down by the delta shift, because it pushes the transfer to “out of the money”. For this pricing model, a zero PV is generated anytime a transfer becomes “out of the money”.

By contrast, when the index, grid-point is flat or shocked up, a consistent PV value is calculated. It is this comparison, using the delta formula ((PVup – PVdown) / 2) that is causing a large delta value to be presented even though the deal leg 1 is not directly projected by Zebrugge.GBP

Alternatives to consider

Having index delta intermittently attributed to a deal side not linked to the index can sometimes cause issues with pre-defined downstream reporting. An alternative to consider is configuring the pricing model to always report pv (and thus delta) to the delivery deal leg, which would might simplify handling of the raw result output.

Alternatively, to avoid the on/off nature of the 0/1 Discounting an extrinsic pricing model such as Black Spread could be considered, though it should be noted that a quanto spread model would be required where the deal legs are not in a common currency, as is the case in the above scenario. As a compromise where a quanto model is not available, it can be acceptable to manage the currency conversion outside of the deal by configuring a price curve in the alternate currency, though this configuration would not allow inclusion of fx volatility during valuation.