Let’s be honest. As a CTRM/ETRM solution provider, you can be cloud-native and yet do a poor job at offering real price elasticity when intensive computing tasks need to be performed. You either have the right design or you don’t.
In the old days, software was installed locally, making the running of complex calculations time-consuming and expensive. You needed hardware for your production and back-up environment that could manage the peaks of your activity. It was resource intensive. Some reports could take more than eight hours to be generated. If anything went wrong, because of unreliable or incomplete data, traders and risk managers alike needed to start their day unsure of their positions, their Mark-to-Market, P&L or their risks.
Most of today’s ETRM/CTRM solutions were developed more than 20-years ago and have not been able to move away from these prohibitive issues. And a staggering 80% of the market still has to live with these design issues.
TWO STEPS FORWARD, ONE STEP BACK.
Having said that, things improved when grid computing came along. The idea then was to cut calculations into multiple smaller jobs, send them to different machines or processors and aggregate them back at the end. Starting in the capital markets space, most of the leading vendors adapted their software and risk engines so that the computing effort could be distributed to stacks of CPUs. That solved a huge problem from a computing time perspective, but did not help reduce total costs of ownership. In fact, it made matters worse. It seemed that efficiency came at a price.
If everything was done to limit the number of additional processing power required by using available computers (as people finish their day), it was not enough to help the largest organizations. Some of them had CPU farms courting tens of thousands of units.
PASSING THE BUCK.
The Cloud came as a relief. Private and public hosting provided scalability and security. It did not eradicate the burden of buying and maintaining the hardware was shifted to hosting companies who would own, Clients paid for managed services. And still, TCO did change.
Luckily, the ETRM/CTRM landscape has evolved, with more vendors offering cloud-based solutions that address (and solve) many of the issues stated earlier. But not all have resolved the cost issues.
Cloud-native development has changed this paradigm by leveraging technology offered by the Cloud giants – Amazon, Google and Microsoft Azure. These leaders have been able to offer more flexible pricing based on fluctuating computation requirements.
HOUSTON, WE HAVE A PROBLEM.
But there is still a problem: most of the so-called cloud-native software has not been designed with the right architecture in mind. In most cases, the software needs to be told what computing power is available and then rebooted to accommodate the new configuration. This can happen several times throughout the day. As a consequence, the organization ends up paying full-time for a processing capacity they will use for a fraction of the time. Yes, it’s quick computation, but comes at a high price.
HOUSTON, WE HAVE A SOLUTION.
In this respect, CTRMCloud has broken the mould. Our architecture is built so it automatically determines in real-time what is the highest number of jobs any calculation will require, reconfigure itself accordingly, and send an automated request to the hosting company for it to make the necessary processing power available. All that in a millisecond.
The simple reason behind is to keep costs down. This architecture allows us to take advantage of the per minute pricing model that Cloud companies offer.
At CTRMCloud, we can fully value 100 million trades in under three minutes. We calculate P&L attribution with full valuation – no estimates. We can accurately and immediately compute Value at Risk for all confidence levels at once without the end user noticing. No extra or hidden costs. It’s on us.
If your risk reporting is taking too long, you should talk to us.