Terminaling services — Fee Capturing Tool

Terminaling services — Fee Capturing Tool

Photo by <a href="https://unsplash.com/@chris_pagan?utm_source=unsplash&utm_medium=referral&utm_content=creditCopyText">Chris Pagan</a> on <a href="https://unsplash.com/@chris_pagan?utm_source=unsplash&utm_medium=referral&utm_content=creditCopyText">Unsplash</a>

Photo by Chris Pagan on Unsplash

Amid the prolific and expanding LNG industry worldwide, the massive influx of Liquefied natural gas in Europe makes the Old Continent the third-largest trading region for LNG import, following Asia-Pacific and Asia. The amount of LNG import into Europe has reached nearly 80mtpa out of 356mtpa total global LNG trade volume.

Despite being hard to compare with the vast quantity in the Asia-Pacific region, the overall regasification capacity in Europe amounts to 179mtpa. There are currently 37 operating terminals, and more are to be built by the end of 2021 (currently in the EPC stage, or the planning stage FEED, FID). Considering Europe’s largest LNG receipts from Spain (45 MTPA) and UK (38MTPA) in addition to the ongoing construction of new import facilities, one can conclude that stringent transparency requirements are necessary. Introducing such measures before the Terminals Operators would support a more competitive, accessible, and fair market environment. Otherwise, commercial data on roughly 37% of the total EU send-out LNG capacity will continue to stay publicly unavailable.

Not much has been done recently to tackle the information opacity and complexity, which according to the Council of European Energy Regulators is ‘evident to be a potential barrier against new LNG Imports.’ In a way, to a lesser extent, there is an existing GLE Transparency template (GIE/GLE), implemented voluntarily against the LNG system operators. However, this concerns the generic Terminal characteristics rather than the commercial information, which is more vital for making informed decisions, such as regasification costs. That being said, a substantial share of information about the European regasification capacity remains a grey area. The UK receiving terminals are such an example.

To sum up, there seem to be three peculiarities that may raise caveats to the European LNG trade:

  1. Lack of genuine level-playing field— A handful of Import Terminals (6 LNG Terminals) are under an exemption regime. In the matter of data accessibility this would mean that all the commercial information regarding Tariff and Fee structure is not disclosed, but strictly confidential (e.g., basic services such as Unloading, Storage, Regasification).
  2. Lack of service standardization— Presently, there is a substantial tariff variation.
  3. Poor-quality information— All in all, the information published is not illuminating. On the contrary, it is rather incomplete and of questionable value regarding the usage of LNG Terminal services. In addition, there is a limited understandability since national legislation for some of the European LNG Terminals is rarely translated. In the end, all this will open doors to more inefficiency, confusion, prolonged time frame for commercial information gathering, leading inevitably to market distortion.

What role can RoITi play?

RoITi Ltd. as an organization aims at bringing answers to major questions in the energy sector, sparing no efforts in going after ‘the sweet spot’ of the synergistic relationship between Energy and Software. By solidifying the role of the software in energy, through adopting our proposed digital solutions, the LNG shipping companies are expected to benefit from these smart solutions.

RoITi ‘s concept focuses on the LNG Import Terminal Services, and more particularly on all the expenses incurred between the Berthing/Mooring process ending with the Injection process into the National grid system (e.g., tariff tables, fees, all fines, and penalty charges etc). That is to empower future software users to unify the energy management across the full spectrum of LNG import locations by giving them control over the tariff structure and the ability to optimize its deployment and management for the benefit of their organization.

We are working on a design of our proposed digital solution, (e.g., “multi-Terminal” Calculator). In our framework, users would have the right tool designed to facilitate the entire process of acquiring information in a more versatile way in terms of having a good grasp on the Tariff tables and fees for more than one Terminal. This will help the LNG shipper by obtaining the necessary information at the right time with minimum effort.

Follow us on Medium for more insights.

Gas Storage – Always a Good Challenge

Gas Storage – Always a Good Challenge

Gas Storage – Always a Good Challenge

In my book, gas storage is among the most complex types of contracts to implement in an ETRM system. Below, you will find the challenges that an implementation will face when gas storage is concerned.

Contract terms

There are three main aspects of a storage contract:

  • Working gas volume (WGV) – how much gas you can have in the storage at any given point during the contract period
  • Injection capacity (IC) – how fast you can inject – typically per hour or per day
  • Withdrawal capacity (WC) – how fast you can withdraw

Some operators also have additional options or limitations:

  • Overrun penalties (balance going above WGV or injecting more per hour or per day than your IC or withdrawing faster than WC)
  • Seasonal limitations on IC and WC – depending on technology and whether overall the system is in “injection mode” or “withdrawal mode”. Essentially, if you are going against the flow, it either cannot happen fast enough, you have to pay more for it – or both of these

Capturing the different terms for the payments of the above conditions are typically complex to understand and model – they may be:

  • lump sums (typical for WGV)
  • volumetric payments – price per injected or withdrawn unit (for IC and WC)
  • a combination of the above
  • based on a fixed price or indexed to pretty much anything – I have encountered summer winter gas spreads, power indexing against year ahead contract, and a combination of the two

Volume movements

Once the storage contract is captured in a system, the more interesting movements affecting the balance also require some thinking.

To start with, capturing the initial fill level may be a challenge. There are two key items to it. You have to adjust the balance under a specific storage contract, but this is not an injection – gas is already there when you sign the contract – however, if you model the contracts separately in a system, you have to move from one to the other. Also, the value at which it enters the storage is a question – especially for the initial capture of a storage deal that may have ran for years.

In storage transfers are also a topic to consider, which is similar in terms of how it affects the balance – and easier to value. With them, gas is changing hands in the storage facility itself – often done with counterparties as a swap against a hub position to save injection and withdrawal fees. The complexity coming from these is to adjust the balance without adding in the system an injection or a withdrawal. Besides affecting the balance in the facility, the actual transaction with the counterparty has to be captured – and it may be a challenge to do these in one step for some systems.

Normal injections and withdrawals are usually straightforward to capture. The interesting part is what happens when a storage user goes into overrun. Ideally, the ETRM system should automatically calculate the penalty.


For the trading/portfolio management purposes, storage is typically valued as a time spread:

MTM (storage) = (Pwth*Qwth – Pinj*Qinj) – Total Storage Costs


Pwth, Pinj  are the market prices at the times respectively of withdrawal and of injection.

Qwth, Qinj are the quantities withdrawn and injected in the storage

Total Storage Costs are the payments for WGV, IC, WC, and overruns and other penalties

Note that for the calculation to make sense, Qwth has to be equal to Qinj – otherwise there is an unaccounted for imbalance between injections and withdrawals. This means that an estimation of when injected gas will be withdrawn has to exist and be marked against a forward curve. This is often counterintuitive – and sometimes an egg or a hen question arises – do you plan injections and withdrawals and then hedge against the plan, or do you buy and sell gas, and then see how storage fits in… Both ways are valid – again, depending on market conditions and company tactics.

In the case when injections and withdrawals are planned after some optimization process, the question of how you arrive at the plan comes up. And is the optimization part of the ETRM system – or a separate tool used for inputs.

Overall, storage is a really good exercise in stretching software capabilities. In my experience, the multiple views you can have on a storage (from the market perspective, an injection is a short position, but from the storage perspective, it increases the balance), and the complexity of the contractual terms and volume movements are not covered in any system completely.

Written by Ventsislav Topuzov

Gas Capacity Medley

Gas Capacity Medley

Gas Capacity Medley


Gas capacity is every time a fun topic. I have tried multiple times to say something along the lines of “the standard approach is…” – and every time it didn’t end well in terms of number of reworks to whatever came in place of the three dots. It is both the simplest and one of the difficult conceptually topics.

The easiest in the sense that you must capture two things:

Ø  How much MWh can you transport?

Ø  How much are you paying?

It is one of the difficult ones for several reasons outlined below.

Figuring out who is responsible for capacity – and where?

When trading gas at a border, a border point is a flexible term. As an example, let’s assume gas is sold at Oberkappel – on the border between Germany and Austria. This usually means that the seller delivers the gas at the “point” after exiting Germany and before entering Austria – in which case the seller is responsible for the exit capacity from Germany only – and the buyer has to take care of the entry capacity into Austria.

In order to handle this scenario a system needs to be able to capture the following information in some manner:

Ø  That a physical trade done at Oberkappel can be on the German side, the Austrian side, or at the point in the middle

Ø  That capacity at Oberkappel can be either entry or exit at either the German side or the Austrian one

If the system is to provide useful decision support information, it should be flexible to provide room for rules of implying capacity needs – i.e. to imply a need for exit capacity if the company has sold at Oberkappel but does not yet have the capacity to exit Germany.


Figuring out the value of capacity

The value of capacity is another topic that can get fairly complicated. Some companies tend to ignore it, assume capacity is sunk cost, as they only buy it when they need it. Others, who buy capacity longer term, however, keep an eye for how much money they can make of the capacity they already have and whether they should plan cross-border trades to take advantage of it or sell it.

Generally the value of capacity for a certain border and direction (to use the same example – from Germany to Austria) would be calculated as:

Value of available capacity = Min Q (ExitGermany, EntryAustria) * (PAustria – PGermany) – Total Capacity Cost



          Min Q (ExitGermany, EntryAustria) is the minimum of bought exit from Germany and bought entry into Austria. As they are capacities are bought often at different tenders, they can be different – e.g. if you buy 100 MWh/h exit from Germany and 95 MWh/h entry to Austria, you can only transport 95MWh/h for the period

           PAustria – PGermany is the spread between the Austrian market prices and the German ones, which tells you how much money you are going to make (if any) when you export from Germany to Austria

          Total Capacity Cost is the total amount of money you paid for the 100 MWh/h exit from Germany and the 95 MWh/h entry to Austria. Essentially, this example shows that you pay for more capacity than you can effectively use.

The bundle capacity tenders are addressing the latter issue, making sure a market participant can buy entry and exit at the same time. However, especially looking at central and eastern Europe, they are not the standard yet.


What if the value goes to zero

The interesting question in the calculation above is how you treat situations when the market price spread is negative.

There are again – based mostly on market liquidity and company specifics – two approaches:

Ø  If Value of capacity drops below zero, then report zero value. Assumption here is that you are not going to transport gas if you are not making any money – and instead you are going to close the positions on both sides of the border

Ø  If it goes below zero – show the negative values as well. The premise here is that there may be trouble closing off positions on both markets (for illiquid markets) and imbalance cost may be higher than the losses incurred.



I guess the main takeaway should be to not leave capacity for last, as it turns out to be a more interesting and twisty topic than it looks at first sight. I have made the mistake a more than once already and am still trying to learn .

Written by Ventsislav Topuzov




I recently had what I originally considered a fairly low challenge project – implementing gas deal capture at a European power and gas trader. Since I have implemented gas a few times, this was looking unpromising. A small catch: I used to set up trading on TTF, NCG, Gaspool, NBP, etc. – all more or less established and somewhat standardized markets. My customer operates in Central, Eastern, and Southern Europe – Croatia, Hungary, Slovakia, Romania, Italy, and Spain – mostly less liquid and less standardized markets. A few surprises awaited me there and below is a summary of the nicest ones.

It is not possible to have different MWH units! Right?

This one leaves me still feeling uncomfortable :). I thought that a MWh is a MWh however you look at it – after all it is a measure of energy, and 1 MWh energy should be 1 MWh energy in any case. Well, a few TSOs beg to differ. I configured units like MWh NCV and MWh GCV (Croatia and Hungary), as well as MWh 0⁰C and MWh 15⁰C (Bulgarian/Greek border – apparently 1 MWh in my home country is different from one in our southern neighbors – and there is an official document guideline to prove it for disbelievers like me). Of course, we don’t have to forget the Joules NCV and Joules GCV and all Kilo-, Mega-, and Giga- variations (Hungary used to settle things in Joules, some legacy contracts remained).

Just when I was coming to terms with the new units, we got to the regulated fees. To keep a boring long story short, I will just point out my favorite: gas odorization fee in Hungary, which is priced in liters, with a norm of liter per cubic meter, paid on deals in MWh or – to spice things up a bit – in Joules or any variations of the two. The norm differs in summer and winter and the definition of what is summer and what is winter also differs year on year. Enjoy!

Location setup should be easy – anyway most of the trading is on the hub! Right?

Another fun topic was setting up the delivery structure. There is a surprising number of physical locations in the central European markets. There are hubs (occasionally), but in this case money was very literally made at the frontiers – there is a huge number of border and exit points where trading happens. And while trading on the virtual hubs pools liquidity and standardizes, the desire to make things more comfortable for customers and to avoid licensing costs pulls trading towards exit points and border points between exit and entry.

As a bonus on this topic: try to spell and then pronounce Drávaszerdahely and Átköto vezeték 🙂

Prices and ToP clauses

Pricing and ToP clauses were another aspect that tried to fry my brain before we got close to a solution. Flexibility with pricing was a priority and cases with gas indexed prices, fixed prices, and oil-indexed prices within the same contract were not very rare. Also, you could see multiple currencies for each of these pricing logic and there were several unsuccessful attempts on the way to agreeing on and then calculating the correct FX exposures. Of course, ToP clauses could be different for the quantities priced by the different pricing logics as well.

All in all: CEE and SE gas markets pose a very beautiful challenge – I am excited to see how they develop and help out new customers along the way. 🙂

Written by Ventsislav Topuzov





Recently EEX has launched wind power futures for Germany and Austria to help wind power producers or asset owners manage volume risks and wind induced market price risks. The purpose of this post is to share some thoughts on the applicability of this and similar products for hedging, as well as some issues one might have when calibrating and applying a hedge on own asset(s). The topic will definitely be open to further discussion and exchange of experience, especially when the products actively used for risk management and liquidity start to build up (or not).

With the growing market penetration of renewables across Europe, hedging power from renewables becomes an important issue. Asset owners are understandably looking to reduce the uncertainty of energy output, despite subsidy scheme or wholesale marketing. The number of market participants whose revenues are dependent on the supply of renewable energy is growing as well. To meet these needs, products such as insurances and futures are being developed. However, given the heterogeneity of wind producing sites and the specifics of each asset park or class, a lot of issues arise around the applicability of a single (standard) product as a hedge. Potentially significant basis risk might cause both cashflow implications and inadmissibility of the hedge for accounting treatment purposes.

According to specifications, the underlying is represented by an average wind load factor per period, creating a “baseload” of sorts, based on meteorological data provided by the German Weather Service and turbine database updated on monthly basis. Here is a list of some sources of risk:

• Risk profile and calibration
Difficulties for hedging might arise from wind conditions at a site not matching the wind speeds collected by the meteorological data. Furthermore, the load profile or curve used to transform wind speed data (m/s) into electrical output (MWh) might significantly differ from the turbine type specific curve or the dispatch by the operators. As a result, the hedge instrument might result in a payoff from the buyer (hedger) to the seller (dealer, exchange) not compensated by higher revenues from high wind output. A related issue is how to calibrate onshore met data to offshore wind conditions, as these might differ significantly.

• Availability of assets
Further issue is the technical availability of assets. While turbine manufacturers guarantee a certain technical availability, any unexpected outages not covered by the insurance might trigger payments for the derivative while not generating actual revenues or compensations.

• Price levels
Different subsidy levels and mechanisms are also key in determining how much revenue an asset owner is losing when the asset does not generate. While insurances usually provide individually tailored notional compensations per MWh (based on asset owners’ expected revenues), this is not the case for the broadly defined wind power index. Hedging a renewable asset with a fixed remuneration per MWh based on average load data only (where 1 % equals 1 €/h according to EEX) would hardly compensate for the risk of losing the subsidy, nor the cost to rebalance the portfolio due to over- or under-generation (imbalance cost).

• Intermittency costs
When using an average (baseload) price to mitigate revenues, an issue arises with the so-called profile cost and seasonal uplift of a particular asset or portfolio (majority of renewable production usually during lower priced hours due to the merit order effect). As the load factor is the main determinant of the Wind Power Index, the latter will be unsuitable to mitigate this kind of market price risk. In this case, the best hedge would be to pick a location which best matches the wind output profile on a country level.

Based on the contract details outlined by EEX, wind futures will probably be more suitable for market participants who are not wind asset owners, but are somehow impacted by the wind generation (be it price or volume effects). The latter won’t be confronted with the operational issues described above and the determination of the sensitivity of their portfolios to changes in wind profiles is expected to be more straightforward.

Taking the complexity of calibrating futures to serve hedging purposes into account, a logical question arises whether entering into such contracts constitutes a well-informed bet rather than a hedge for future cash flows? The answer certainly depends on the analytical abilities and specifics of each business. Or maybe sometimes purely on luck?

Reference: https://www.eex.com/en/products/energiewende-products/wind-power-futures/overview

Written by Konstantin Grigorov

Achieving a Reliable Front Office Reporting in ETRM systems: Typical Pitfalls

Achieving a Reliable Front Office Reporting in ETRM systems: Typical Pitfalls

Achieving a Reliable Front Office Reporting in ETRM systems: Typical Pitfalls

Are you the most trusting person on Earth? If that is the case, you obviously, haven`t dealt with front office reporting solutions, nor have you ever opened a bag of chips.

As the saying goes „Trust is the hardest thing to find and the easiest thing to lose”. When it comes to front office reporting and traders it is even more fragile than a gold fish`s memory. A couple of wrong position results may lead traders to feel like they are using a gambling tool instead of a reporting tool.

A front office reporting project can be complex since it relies heavily on components such as deal modeling, curve/volatility configuration, and simulations results. All of these need to be properly configured in the system in order for front office reports to be correct.

BIG mistake – Reporting is left to the end of the system implementation as it depends on so many system components.Delays however, may result in a rushed reporting roll-out and could lead to issues that subsequently only show up in Production. At this point, since traders rely on front office reporting for position management, this could be easily classified as a showstopper.

By their nature front office reporting projects are rarely straightforward, but typical pitfalls can be avoided if the following points are considered:

  • Front office reporting is a team effort. It requires collaboration between:
    • End-users – need to define requirements in terms of the type of data they want to see, details of how the data should be organized, and performance expectations;
    • Business consultants – need to map end-user requirements to the system`s features and identify any gaps between requirements and system capabilities;
    • Technical consultants – need to take the performance expectations from the end-users and the front office configuration elements from the business consultant and map this to the system configuration.
  • Front office reporting is often underestimated by thinking it is just as a simple matter of putting the appropriate columns and filters on a page. Instead, it is important to understand the actual data to be produced, and what it will be for each deal type in scope.
  • The process of analyzing the data given by the reports and comparing against client needs is not started early enough in the project timeline. It is favorable if a design document for the reports is to be created early in the project, even if the pages themselves cannot be built yet.
  • Estimation of how difficult something is to be completed during implementation is often done by analogy. This however sometime fails to appreciate the differences between underlying data, especially in regards to granularity.
  • Overseeing a needed customization is costly in terms of additional time and effort necessary. Furthermore, due to the sequential work among multiple teams, it can often lead to project delivery delays.
  • Focus on the server side first. Take into account reports` sizing and performance early in the project. Inappropriate technical sizing may lead to production issues. Front office reports may deliver correct numbers when a deal is booked in isolation but that doesn`t necessarily mean that they will work optimally when under peak load, if the hardware is inadequate. This sizing adequacy is driven by business requirements which often change over time.

Taking note of the above pitfalls could save you and your clients a lot of frustration. Failing to acknowledge them will lead to a reporting that users are reluctant to use as they do not trust the results.

Written by Maksim Yachev