CHALLENGES IN CROSS-COMMODITY SYSTEM IMPLEMENTATIONS

Mar 19, 2015

In complex implementations for bigger energy traders, there is often a need to implement trading of different commodities. When these are close in terms of trading, quality measures, and delivery chain (eg gas oil, fuel oil, crude), solutions are fairly straightforward – you apply a certain logic across the board. When, however, the requirement is to implement flow and bulk commodities at the same time, things get interesting, as these are based on a different production logic which dictates a different market model. This post will cover basics like trading units, settlement units and reporting. In the next posts, we will cover some considerations on risk measurement, valuation, currencies, and other factors that challenge system designers, implementers, and users of ETRM solutions. It will also show why knowing the difference between MW and MWh is a significant step towards the top quartile of ETRM experts:).

Flow commodities

Flow commodities are power and natural gas (in most cases) – where the unit of trading and the price and delivery unit are different. To start with the basics, power is traded in MW (megawatt) – but the price per unit is eg EUR/MWh (megawatt hour) and the settlement is based on the amount of MWh received. MWh is a flow of one MW for one hour. This means:

  • If you buy 10 MW with delivery of 30 minutes, you get 5 MWh
  • If you buy 10 MW for the month of January, you get 7440 MWh (January has 744 hours)

Same logic applies to gas, but with a few twists:

  • In Germany, wholesale trading unit is MW, which brings about a similar case to power (at least before things get to settlement and imbalance calculations, which is done in cubic meters – and the GCV is published by TSOs month by month)
  • In the Netherlands, trading is mostly in MW, but there are also cubic meter (m3) deals (fortunately, the TSO applies a fixed conversion rate from m3 to MWh, so recalculation is easier)
  • In the UK, unit of trading is Therms/Day, while price and settlement unit is Therm – a similar logic applies there – but the flow is daily and not hourly
  • In France, PEG-N trades in MWh/day – again daily flow, but this time measured in MW

Bottom line: unit of trading is linked to the settlement period of the system – be it hourly or daily (or something else) – and the settlement amount is calculated by multiplying by the number of settlement periods within the deal delivery period.

For a system implementation this means:

  • The system has to handle MW as a trading unit and MWh as a settlement and pricing unit
  • The system needs to be able to handle dynamically calculated flow positions. This means for a certain position a good reporting solution should be able to show eg MW on a daily granularity, on a weekly granularity, on a monthly granularity, and on any other required granularity which supports the business model

The latter point is quite complex to achieve for at least two reasons:

  1. The need to combine daily and hourly based flow units and daily and hourly flow reporting:

    Imagine the following situation: there is a gas desk which trades spreads between UK and Germany. The UK positions are in Therms/Day and the German ones are in MW. Obviously, the respective country positions have to be reported in the trading unit of the market. However, in order to make sure the positions are of the same magnitude, you will need to report them both in the same unit – ie both UK and Germany in MW or UK and Germany in Therms/Day or both.

    In most cases, this is straightforward – but for daylight saving days, you will get a difference – as the MW position will produce one hour less or one hour more of MWh depending on whether it is March or October – and the Therms/Day position will remain the same – hence, the MW position for these days will be either larger or smaller than the rest.

  2. Even if you don’t need the scenario above in one report, the system needs to be smart enough to handle both situations separately – ie a way to understand what flow granularity the market trades in, but also allow for differences (an obvious example is the Belgian gas market with its hubs – Zeebrugge Beach is a physical hub which trades in Therms/Day and ZTP is a virtual hub which trades in MW).

Bulk commodities

Bulk commodities like oil, refined products, and coal have different trading units and unit logic behind them. They trade in certain quantities and the delivery is linked not to a specific hour or day, but to period. E.g. you can trade 1000 MT (metric tons) of coal monthly for the first quarter of 2015 which would mean you expect a 1000 MT some time in Jan, another 1000 at some point in Feb and a third 1000 in March. This makes a solution simpler, as trading quantity per period = settlement quantity per period = quantity that needs to be reported per period.

Where the complexity with bulk commodity really comes into play is the logistics. If you have only financial trading things get simpler – the complexity moves to modelling diffs, cracks, and outrights and all the conversion factors between volume and mass units in crude oil and refined products, as well as the NCV conversions between different qualities of coal. We will cover these topics in more detail in following posts.

Flow and bulk combined

Cross commodity trading very often comes into play when the requirement to an ETRM solution is to model power plants – virtual or physical. There, a spread with a specific heat rate is required between the power produced and the potential inputs – be they natural gas, crude, refined products, coal, and the certificates that need to be bought.

All of these in one place mean several interesting requirements:

  • Calculating MW and MWh equivalent of bulk commodities that might fire the power plant – using a plant or model specific heat rate
  • Calculating MW or MWh equivalent of natural gas using a heat rate
  • Calculating emissions exposure based on power produced – again based on plant or model specifics

The above, however, are fairly straightforward if the general functionality covers the specifics of the flow and bulk commodities individually.

(Visited 1,146 times)