Anybody who has spent any time in the world of energy/commodities trading knows implementing a new CTRM/ETRM is a costly and painful exercise, which can take months to years to complete, and worse, sometimes end in failure after teams of people have spent countless hours to make it work. There are too many painful memories, too many colleagues who lost their jobs – nobody wants to repeat it.
So, why do CTRM/ETRM implementations take so long? Trading energy/commodities is a complex business – hence, some of the challenges just come with the territory. However, there is a long list of avoidable factors which unnecessarily lengthen implementations, making them more costly and risky. We will discuss these factors in a series of blogs, starting with the seemingly most trivial one: “reference data”.
When you purchase a new CTRM/ETRM system (on premise or on the cloud), you get an “empty box”, which you have to fill with data before you can use it to conduct your business – your trades and positions, your inventories/physical assets, etc. But even before those come reference data, sometimes referred to as “static data” (more about their “static-ness” later on). Reference data include things like trading books, commodities, locations, hubs, pipelines, power grids, exchange data, pricing indices, units of measure, holidays, currency and FX data, etc. Even though this can be a very long list, most people assume that setting up the reference data should be a quick and straightforward exercise. However, in our many decades of experience implementing and helping implement CTRM/ETRM systems, this part of the implementation typically takes anywhere between one to three months and involves multiple resources.
Does it have to? There is very little in that long list of required reference data that is not publicly available information – yes, your trading books are your private data, but most of the other pieces of data come from various external sources, such as exchanges and other publicly available publications. It does not make sense for you to spend months to collect this information for a CTRM/ETRM implementation. It should just be part of your vendor’s offering.
Some vendors have wised up to this reality and have created “packages” they sell on top of their software license. There are a couple of problems with this – you shouldn’t have to pay for publicly available data. More importantly, despite its name, this data is not really “static” – exchanges make changes to their listed products, start listing new ones, publications make changes to other pricing indices, there are changes to holidays, hubs, nodes, pipelines, etc. You should not have to wait for an upgrade of your vendor’s software to be able to trade a recently listed contract.
Enter CTRM/ETRM as a Service. A modern, cloud-native system ensures clear and secure segregation between each tenant’s private data as well as the shared global data. The global data is there on day one and is continuously maintained by the service provider. You, as the user, do not have to do anything; neither during the initial implementation, nor on an ongoing basis as there are other changes to reference data and/or you start trading a new index, hub, product, etc. It is just part of the service.
For example, CTRMCloud clients only need to choose the exchange contracts and other pricing indices they want to use, and optionally, give them their own name (“alias”) if they choose to. We, at CTRMCloud, have done the labor intensive part of collecting all that information (many thousands of exchange contracts/pricing indices and all of the associated data), which we continuously maintain as there are changes.
Comments