Risk Management in Energy Trading Market: 3 Key Challenges

Risk Management in Energy Trading Market: 3 Key Challenges

Risk Management in Energy Trading Market: 3 Key Challenges

Security, Speed, Reliability

How do systems address those and what are the areas for improvement?

As stated in McKinsey’s article The Future of Commodity Trading, “recent market developments include increased price transparency, greater access to structured and unstructured data […], contract standardization, new exchanges and platforms, and regulations“ resulting in “higher market participation, transaction volumes and costs, and speed to market”.

This results in increased volatility of the traded financial and physical products, and demands a more flexible response to the constantly changing market conditions. Given this, commodity traders and risk managers are facing new challenges and demanding more and more support for technologies. In this article we are going to focus on the top three of them, how systems address those and the room for improvement.


In the energy industry we operate, the risk of hacker attacks has increased due to recent geopolitical events. Data is the core of every trading business and analysis nowadays. Predictions and strategies based on this data are proprietary goods and key to financial success. The main challenge for every company is security. This becomes even more important given the regulations in the energy sector and the requirements for anonymization encryption and disclosure/reporting of transactions to the supervising authorities.

Volumes of digital, online and algorithmic trading are increasing and are supported by tools, systems or AI. The online exchange of sensitive data, as well as investments in IT security also escalate. The setup of proper encryptions, proxies, gateways, VPN tunnels and procedures to protect your data and trading systems becomes a must for every key player in the industry. With that, the area becomes more attractive for software engineers too.

As systems evolve, so do encryption algorithms. Hackers’ creativity grows and the IT security teams must follow. With the increased usage of nearshoring and consultancy services outside of a particular trading company, teams become more global. Data protection and the usage of proper authorization and authentication mechanisms are inevitable. Therefore, step number one in developing any new product, component or whole architecture is setting up the proper structures for granting functional and data permissions and securing the data transfer protocols.

This is an area where IT companies can provide expertise to trading companies, either by ways to customize the usage of already known systems and tools or by helping with the development of in-house systems to ensure the protection of this precious data.


Given the increasing data flows, speed becomes a significant challenge across the whole cycle: accessing, transforming, synchronizing, processing, storing, querying, and exchanging data. The companies that manage to implement the aforementioned process-cycle the fastest, would usually unlock trade potentials and arbitrages inaccessible to the ones who are slower. By using tools, systems and AI-based, self-learning and training programs, it is no longer a matter of minutes or even seconds – but milliseconds. The maximum response times become a key non-functional requirement in every new development. This is the area where an IT specialist can provide significant value not only for traders but for risk managers as well.

Position management in highly volatile market environments requires not only real-time monitoring and very frequent updates of data. It also requires quick reactions to new market trends. Full excellence and high efficiency can only be achieved by optimizing the whole chain of data flows to ensure maximum speed of data handling and decision making – and respectively, taking the appropriate actions. It is possible to improve in the following areas:

  • Optimizing access to data by caching or querying. This can be done either directly on a database level or via the usage of web-based services;
  • Acceleration of data transformation or processing via standardized ETL tools or own programs/algorithms;
  • Ensuring proper visualization of data to drive informed decisions using proper monitoring and BI tools;
  • Optimization of data exchange protocols and interfaces;
  • Applying proper data storage procedures provides maximum efficiency when trying to extract a particular data set;
  • Last but not least: ensure a proper orchestration of all components driving the data flows

The maximum speed in the above areas often results in maximizing profits and minimizing risks (sticking to the predefined limits) by quickly reacting to market changes, one-off events or reversing trends. This is where investments in IT can provide value and returns.


Speed, of course, means nothing, if you cannot rely on the data and the systems. This data should be of the desired quality and without errors or gaps. The systems should be constantly available. With that said, the next challenge is reliability. Without proper validations or constant and continuous/uninterrupted access to it, even the best data becomes worthless.

With the rise of cloud-based technologies, it is possible to deploy services to new services, restart or restore not running machines, and increase computational power remotely within a couple of minutes to avoid long-lasting disruptions or outages. IT specialists can help design the cloud architecture in the best and most reliable way, increase availability and minimize infrastructure/system costs. If traders or risk managers base their decisions on outdated or faulty data, there is a high chance that the decisions are wrong as well, sometimes with significant financial implications.

That is why energy (trading) companies increasingly invest in cloud-based architectures, while still keeping the above requirements on security and speed in mind in addition to reliability and availability. Minimum availabilities are becoming part of almost every contract for IT infrastructure or components. The need for 24/7 incident management and monitoring services increases as well, as trading happens in different locations and markets around the clock.

In summary, with the increased flows and availabilities of data, the volatile market conditions and the ever-increasing online trading, investments in proper IT infrastructure become very important. To maximize returns and minimize risks supported by the proper software and experts, companies need to tackle the challenges related to those continuously and with diligence. IT systems are a powerful weapon – however, if misused, their usage may lead to self-destruction.

Author: Konstantin Grigorov

What (the hell) is ETRM?

What (the hell) is ETRM?

What (the hell) is ETRM?

ETRM stands for Energy Trade and Risk Management. That is, simply put, certain software services that support energy trading and risk management. One can use these services for any part of the energy chain: from producers to suppliers, traders, and large consumers.

Eroslav Andreev is an Expert ETRM Developer and the lead of the ETRM Developers Team at ROITI. In this article, he helps clarify what (the hell) ETRM is about.

What business problems do you solve?

Like everything in the IT world, problems evolve with time. When I started working at ROITI, the main problem our clients used to face was how to get all their raw data into a single application. Many used to use multiple systems. Not all used to have working and stable interfaces between one another, or with trading exchanges.

Six years later, this has somewhat been achieved, and now the problem is what to do with that data and how to use and analyze it profitably. We try to solve specific client problems depending on their maturity level, including integrations with other core systems, automation of tasks, reporting, cost-cutting, etc. In general, trying to make their lives a bit easier. And of course, in between that, I try to teach the others from the team “a thing or two”.

What is the tech stack you use and are there any peculiarities?

This depends on the client, although we focus on .Net for applications outside the ETRM system and Java for the embedded tasks. We use a specific framework, only available for Endur, called OpenJVS. At first glance, it may seem a bit legacy, but it has its benefits over others, such as Spring, for example. Of course, SQL, DevOps, PowerShell, CI/CD, and unit testing are not new to us either.

The main difference here is that you cannot google your way around these systems, so learning is only by the try-fail-succeed experience or by the call-a-friend option.

Who is the “right” kind of person for such a role?

Me. 🙂 Joke aside, as long as one has analytical and detail-oriented thinking, the willingness to learn and develop, and not being afraid of making mistakes and solving undescribed problems, there might be a chance.

What is the most fulfilling part of the job?

Sparing someone even just 15 minutes of dull work by automating it is relieving and reassuring. At the end of the day, going home confident of the changes and implementations you have done during working hours gives you the willingness and motivation to go to the office.

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