The key to this evolution, not revolution, is that most people in business, who have never worked in commodity or energy trading, quickly learn that this space is a paradox.
Trading operates at twenty times the pace than any other company activity, yet it moves slowly in time in comparison to the other technological advances we are now all accustomed to.
How and why does paradox this exist?
If you work in trading, you understand that each and every day, not at month-end, a profit and loss statement is generated, along with untold trading, risk and accounting reports. This makes commodity and energy trading run about 20 times faster than traditional business operations.
Which means that there is no time to stop, discern, evaluate, provide feedback, buy, and implement trading software. Developers can’t keep pace with the trading business. Often times, software is developed client-by-client, which means that any C/ETRM, or Risk system is far from standardized.
Add in that traders – I have been one too – often throw stuff over the wall to the mid- and back-office to discern. They then say the middle and back-office are not keeping pace with the change of our trading and hedging programs. Of course, they are not.
Having spent time working in back-, mid- and front-office roles, I can appreciate the other side of the wall much more! Stopping, and saying “thank you” will be the humbling experience once you have lived each every role, front-to-back.
If you haven’t worked both sides of the fence, by reading this book you will learn why and how software systems are sold to you, and who is the beneficiary of these systems. That will be an irony in itself, but will explain one of many reasons why projects take longer, require more money, and are usually not as successful as expected – i.e. the benefits one can leverage can be uncovered throughout the project, real and perceived.
In getting to the real benefits of commodity and energy trading systems, to bring them full circle from the 20th century into the 21st century, we will spend a brief time on this evolution – the history of these systems – for perspective.
I realize what is important is where are we today, and where are going in the CTRM/ETRM space. History repeats itself though, and it is important to know when, where, why and how your current or prospective CTRM/ETRM firm is headed.
Front-Office System History:
Since the front makes the money, it is still it is the focal point for how and why trading and risk management software systems are developed and sold to clients. Understanding trading portfolios, exposure reporting, and capturing deals is the underlying essence these initial systems brought in the 20th century, and still bring today, to hang their hat on.
After this book, though, your perspective may begin to change.
When these systems were first introduced, they were certainly more physical-transaction based, with deal capture and some basic logistics process steps, to appear like an energy trading and marketing software niche. Many of us new to software in the 1990’s, especially when it really became a big industry, focused on this one front-office feature in search of how it could take a transaction as far into our processes as possible before it had to get extracted – not interfaced, but extracted – and re-keyed so we could continue the customer-to-cash process. It still happens today, but for the wrong reasons.
At this initial stage, the software provided one main feature and that was to ensure the trade was captured. When you worked at Enron, or Koch, or Shell, hand-written tickets were coming in the mid- and back-office in piles, including when the traders were leaving at 5:30 or 6:00pm. Which meant the mid-office had to work for several more hours, with many working not just 12 or 15 hours a day. I had one guy who worked 17.5 hours every day, including weekends. Lance was a hero, and he was treated and respected as one, but he, too, burned out and moved on to bigger and better things.
Just trying to get a trader to enter a trade into these new systems was painful. Today it is expected, and even measured as a part of many traders’ bonus programs. We have come a long way in building expectations and accountability, but is it enough?
For logistics too, it was a start for tracking a physical deal, but as all schedulers experience today, they, too, are a niche group and their software, as we will discuss, is still immature and lacking.
In looking for systems that could take a transaction, in a complete state, as far as it could, which was about to the middle-office for a basic position report, we all realized we needed to ask for reports, that did not come with the system. Not a lot has changed here either.
Reporting was an after-thought, as it usually is in most projects, even today. Big hint.
The reports would serve others who were keying the deal information into other systems. Other systems being multiple, from scheduling to settlement, to accounting, to contracting. Financial reporting, as you can see, was a non-existent thought in those days.
However, since we were running trading books on DOS – yes DOS – the systems could not handle as much data as they can today.
Thirty thousand rows running on these systems was big data then. And, our desktops had memory not measured in GB or MB, but in KB. Even my Sun Microsystem supercomputer desktop was in KBs. Therefore, any data size was not nearly what they are today, so calculations could take all night to run. I know we have similar problems today, but data size is now much greater, and growing by the day.
Risk Systems:
When I say risk back in the day, I mean the ability to calculate a deterministic Value-at-Risk, or VAR. That was usually done through home-grown systems or spreadsheets with one simple, deterministic value published. Yes, we also did it on post-it notes.
Scenarios, and/or simulations then, were rarely performed, save the times I ran untold iterations by changing the price, volatility and correlation curves/matrices in each step in either DOS or Spreadsheets, or in the new ETRM systems. One-off calculations done on the side is the best way to describe those times. Hit the “calc” button, or F9, and go to lunch, the gym, or home, and return at 6am to see the results.
Many are asking what the difference is today in these commodity and energy trading systems? For most of these systems, save a few, we will discuss why you still have the same issue of running scenarios today.
System Performance:
LOL – based on what you have already heard, it was an issue then, just as it is today, and will be tomorrow, for sure. Once this is solved, it will propel the next generation of commodity and energy trading system companies. Options are usually the culprit, modeling assets as options, that is, even using deterministic models, really slows calculation times.
Reports:
I have mentioned this briefly above, ensuring I mention it again, and I will mention in about twenty-five more times in this book. It took me a decade to really internalize this is a key factor in all facets of the system life cycle.
I worked on not only some of the first ETRM systems, but also on some of the first accounting system implementations with software firms who were purchased – D&B had an accounting system which was very competitive and quickly purchased – or still exist today, that were in the same immature state. One of the key things I learned early on was from a project manager who said, “The first thing we have to do before we do anything, is to start this project by defining the reports.”
Defining them by discerning every last data input, and how it must be designed, to meet those reporting needs.
Said another way, why does every company have a data repository?
Reports that were not thought of, changing market conditions, and especially not having thought through the reporting needs and then backing those needs into the very specific data attributes.
Today, I still have yet to see someone make the suggestion at the beginning of a project as I did on my first software project. A few have, though, and I will make an example of that later to bring history to full circle, to ensure you develop a great
process and a great project outcome.
Back-Office Evolution:
There was nothing. I assume you expected to hear this. Nothing designed for the back-office, not even an invoice just twenty years ago. Today there are systems that still produce nothing more than invoices. There are others that have all sorts of functionality to leverage.
Software Players:
In this book I will not use any software vendor or consulting firm names. The reason is that any use of any software firm impedes my, and our, independence in providing service to the industry. To suggest one firm over the other, or to even mention a firm can create perceptions that I may not intend to create.
I will state that I have worked to help some, over others, develop their first modules, including bringing them into new products. For example, when a firm tried to sell me a physical natural gas system while working in crude oil in both physical and financial derivatives, they had to modify and create new modules. They did it well, and timely.
As a controller, I had a summer intern, a junior from Texas A&M, running the mid-office oil derivative book; that is how good that system was developed and easy to work with. We hooked, just as many do today, one of the major option valuation tools, old-school black-scholes. If you read Steven’ Trading And Risk Management Strategies books, these models are an issue.
Today, there are still systems that I could not teach a college intern to run over the summer. Between evolving and being more user-friendly than others, though, there are better choices to consider, now, than ever before.
The key point is that I have seen how and why one of the key players, who was sold at least twice in the last five years, was much more successful than others who had started twenty years ago. I witnessed, first-hand, directly to the top, how they operated
their companies as compared to others. I, therefore, know what it takes to make them successful. I have also seen the laggards who just hang on.
In knowing this, I will convey why it is important to look not at the number of years a software vendor has been in business, but where they are now, and especially where they are headed. Therefore, the players who started this industry are important in moving the industry forward. Where we go from here will be key.