ETRM: WHERE’S THE FUN IN NATURAL GAS?

Where is the fun in natural gas within the ETRM universe? Following on the more general post on flow and bulk commodities, we wanted to go a little bit into the individual commodities and try to describe where the fun in each of them is. Natural gas won the first place, as it is a personal favorite, and it is probably the commodity that we have implemented the highest number of times.

Market Specifics

Several topics belong here – the differentiation between TSO and market area, the valuation within and across markets, and the units of trading. More details on each are below.

TSO vs Market Area

Typically, in the natural gas market, the area of a TSO and the market area coincide. A prominent exception is Germany and I will take it as an example.
In the past 5-6 years, the market areas there have been reduced to 2 from 16 (to boost market liquidity) – but the number of TSOs is still 16. This means that if you want to model the delivery structure you will need to balance between capturing the market area (in which the traders are interested) and the TSO area (which is key for the scheduling teams). Additionally, you will have to deal with points on the border between market areas and TSO areas simultaneously. Suppose the system is primarily used for trading. In that case, you can get away with modeling the market areas only – the problem with such an approach is that you would have to enrich the data before putting it into a scheduling system.

Valuation

A second thing that requires thinking when configuring is the valuation of different types at the same location. For example, a forward contract is valued at the market price of the market area but an entry or exit capacity contract in the same market area on its own is valued at zero (we need to keep in mind the difference between pricing and valuation). The value of capacity can be calculated only when you have two parts. One is the exit from one market area and the other one is the entry into a neighboring one. That is still obtained at two separate biddings from different TSOs in many cases, despite the recent introduction of bundle contracts, which should make things much more straightforward.

The implication of the above for a system means that a categorization of locations is required, which should be tied to the valuation you apply at the specific location.

Units of Trading

Units of trading – and I would add settlement – are typically supposed to be a straightforward topic, which should be easy to grasp. SUPPOSED to be – in my experience, this is one of the things, that projects tend to underestimate until it causes a lot of defects during UAT.

For gas, the main issue is switching between granularities (daily vs hourly units – eg Therms/day vs MW) and between volumetric and energy units – cubic meters (cm) and MWh. The first one is a problem mostly because of daylight saving days, where a straightforward division by 24 does not work. The second one is solved differently in different countries:

• The Netherlands uses a fixed conversion rate between cm and MWh, which makes trading and settlement easier
• Belgium has two – one for high calorific gas, a different one for low calorific gas
• In Germany, TSOs publish the calorific value after the deliveries for the month have been made

A variable conversion rate by location and time is something that makes a system implementation overly complicated. Often, a better choice might be to accept a certain minimal level of error and live with it, rather than bear the costs of a system implementation (or, to use some words that should probably be forbidden: move to Excel).

Types of Contracts

The different types of contracts bring different types of complexities. Below is an overview of some of the interesting ones. I am skipping over futures, as they are standardized contracts, and the functionality there is not necessarily gas-specific (and – as in other cases – we are planning to dedicate to them a separate post).

Forwards

The forwards are typically straightforward to model. Some of the more complex ones are floating forwards, where formula functionality will be needed to capture price dependencies on different indexes, and weighted average publications (eg Heren’s weighted average month ahead publication). The latter brings in complexity, as the publisher takes into account the prices and volumes of all month-ahead transactions within the current month when calculating the publication for today. This has two implications:

• The price will settle on the last day of the current month against the last published price
• Despite this, there needs to be a delta decay on each day within the month (as the exposures decrease in reality)
• Depending on how you model underlying prices and historical prices in the system, you might need to calculate your current price estimation as an average between the last known price for the publication and the balance of the month’s price

Storage

In my book, gas storage is one of the most complex to implement types of contracts. I will look into gas storage in more detail in the following post, but below in short are some challenges that an implementation needs to face when gas storage is concerned:

• Capturing the different terms of working gas payment, injection, and withdrawal payments (which can be based on prices of different commodities – power, gas, LNG, etc)
• Capturing the initial fill level and reflecting it correctly in the balance and the value of the storage
• In storage transfers and their reflection in balance and value
• Valuation – gas storage is typically valued as a time spread between the value at the time of withdrawal and at the time of injection

Capacity

Several scenarios regarding gas capacity need to be thought through. Capturing entry and exit capacity is the first one – including the typical lump sum payments for them. The second is bundle capacity which is a multi-legged deal – having legs in 2 different areas. Finally, rarely in my experience, there are still some point-to-point capacity contracts, which are technically similar to the bundle ones (in that they are multi-legged) but different in terms of points of origin and destination – they are not two sides of a border.

Along with the modeling of these contracts, the valuation needs to be considered – practically an option on the min (exit, entry) capacity at a certain border.

Options

Options are a fairly big topic, so I would rather deal with them in detail separately. The main things to mention at a high level are the need for different exercise granularity options – eg daily, monthly, quarterly (meaning the decision to exercise or expire would be taken each day, month, or quarter), and the need to determine a business and a system process (e.g. who and when exercises, what happens upon exercise – is there a separate contract or not, how the value of the underlying is calculated once exercised, which pricing model will be used, how the volatility and correlation data will be calculated and imported/used in the system).

These are on a very high level, some of the interesting challenges in a gas implementation. Following up on this overview, there will be deep dives into the specific topics regarding individual contract types in terms of capturing and valuation considerations.