The functionality required of a Commodities Trading and Risk Management System is generally much more sophisticated than that found in systems designed for Equities or Fixed Income products. This is driven by the physical nature of the traded products, introducing quality, location, and logistics dimensions into the risk equation.

Drawing on our experience of building commodities trading businesses in the physical, derivative and asset management spaces, in this paper we offer a possible high-level road map for the CTRMS selection process, followed by a discussion of some specific issues that we have encountered along the way.

 

High Level Strategy

 

 

A

The process typically begins with the firm mapping out its complete requirements. This needs to go beyond its current business requirement, incorporating future growth plans in terms of both head count and product coverage.  A priority level can be assigned to each item and non-negotiable functionality made clear at the outset.

This process generates the best results when it involves all stakeholders in the business, from operations through to senior management. Amongst many others, some of the most critical considerations would be:

 

 

The next step is to research the vendor space.

Map out the high-level functionality of each vendor’s platform. Which products, processes, analytics and solutions can it provide?

Consider whether all of the purported functionality is available ‘out of the box’, or whether some of it is only available with additional layers of programming on top of the core system’s base layer.  If the latter, do you have that expertise in-house, or are you willing to budget for that? Once this is done, compare these to your requirements and capabilities identified in step A arrive at a short-list of contenders.

 

B

 

 

 

C

Request proposals from short-listed vendors and enter a detailed due diligence process. Later in this article we discuss many of the specific issues that need to be considered at this stage of the selection process.

Subject to satisfactory pricing negotiations, select the platform of choice.

 

 

 

 

Implementation. After a long due diligence process it may feel as though the hard work is behind you. However, for the CTRMS to live up to its promise a thoughtful and customised roll-out process must be designed and implemented.  During this stage it is essential for the expectations of client and vendor to be properly aligned. Be careful to ensure that:

  • the scope of any implementation work that you require from the vendor is included in their costings. In particular:
    • they may have under-estimated the complexity of your internal risk and accounting hierarchy, in terms of how many trading books or accounts you are running, or how you need the risk views to be sliced (by book/trader/team/commodity type/investor).
    • is your universe of 3rd party entities that you transact with particularly large? Every entity that is involved in a deal, be it an agent, service provider, client, or an execution or clearing counterparty (and their associated commission schedules) need to be set up in the static data
    • consider who is responsible for processing the migration of the existing portfolio. Normally the vendor will do this as part of the implementation, but if your business involves a lot of customised OTC deals you may need and/or want to be involved in this process, and certainly to sign off on it
    • specify the management information suite you will require. Many reports will need to be customised and this should all be completed prior to the go-live date
  • you agree a rigid timeline for roll-out and a detailed list of responsibilities and deliverables

D

 

 

Whilst this is a valid framework for any CTRMS selection process, the degree of work required in parts C and D will be much greater for established companies that are likely to have a multitude of legacy operational and reporting systems. As the latest generation of CTRMSs have evolved far beyond what was available 10-15 years ago, it is a realistic goal that your platform of choice can consolidate and replace many of these disparate systems. Nevertheless, from a practical perspective a large conglomerate or banking institution will need to think not just about what they want their CTRMS to do, but also consider the knock-on effects that replacing their old risk management system will have on the ecosystem of applications that were linked to it.

 

Specific issues to consider during your due diligence phase

 

How has the vendor’s platform evolved?

Did they start with a specific core competency that you require (e.g. agriculturals, or power) and build out, or was it originally a multi-asset platform that added commodity functionality at a later stage? The former will more likely have been designed with the full life-cycle of your commodity in mind, and idiosyncratic issues will therefore already have been encountered and solved.  A multi-asset system will be likely to have a greater suite of functionality due to it having a large and varied client base, but are you prepared to compromise on the basic functionality of the commodity transaction workflow in return for that?

Has the platform evolved organically, or via acquisition? If the latter, be sure that the purported suite of functionality exists in a single application. Multiple applications are more cumbersome to use and maintain, and may present barriers to interoperability between themselves or other software.

System performance and business continuity

During the due diligence process be sure to get a demonstration account, upload some representative portfolios and test the system’s speed and performance with ad-hoc risk report generation.

Consider platform stability, both in terms of how the platform behaves running on your networks, and vendor platform uptime.  Regarding the latter, all will tell you that downtime is virtually non-existent, but your due diligence process should get comfortable with their continuity and back-up protocols.

Consider the business risk of the vendor. How well established and capitalised are they? Balance lower business risk of an established vendor with the fact that smaller vendors may be more responsive to you and your needs.

Has it been designed with your products and business model in mind?

In our opinion it is far more important that the CTRMS can easily book, represent and manage your trade lifecycle than it is to have advanced analytics or other seemingly impressive functionality. Most platforms will have an interface through which data can be queried and exported allowing sophisticated analysis or cutting-edge functionality to be bolted on via in-house or 3rd party applications.

The primary question is: can the system truly represent the processes and risks that your business faces?

For example:

  • Procurement
  • Logistics
  • Inventory Management
  • Trade Finance
  • Contract Management
  • Physical asset optionality
  • Derivative portfolio risk
  • Credit risk
  • Regulation & Compliance

Can it properly represent the idiosyncratic nature of your traded commodities? For example:

  • Commodity quality/grade/location
  • Allocated/unallocated accounts
  • Blending/assay
  • Pricing conventions (for example custom Quotation Periods for averaging)
  • Allow risk to be represented in different native units (e.g. bbls, ozs, mt, bushels), currency or relative percentages (e.g. bps of Assets Under Management)?

How much in-house IT expertise and resource do you have?

The good news here is that most CTRMS can now be delivered over the cloud, meaning no requirement for local server hosting and an easy software update process. In many ways it is easier than it has ever been for a company with limited IT expertise to employ a sophisticated risk management system solution.

At the same time, the case for in-house programming expertise has never been stronger. This is because modern CTRM systems are being designed with extendibility in mind, meaning that if you already have (or are prepared to hire) staff with programming skills then a high degree of customisation and functionality enhancement may be attainable. Think custom valuation models, user-defined formula-driven parameters, and communication with your other in-house systems.

Total cost of ownership

How much of your required functionality is included as standard, and what is priced as extra-cost bolt-on modules.  Are services such as the support helpdesk included? Who is responsible for the cost of system development should a regulatory change occur that necessitates new reporting functionality that affects all market participants?

The fee model is generally specified by number of named users, although larger firms should consider an enterprise-wide license where that makes sense.  Vendors who are newer entrants to the CTRMS space are often willing to consider more innovative fee structures. For example, we have seen start-ups on tight budgets opt for a CTRMS deal that back-loads costs to years 2-3, and small Asset Managers sometimes negotiate the fee to be a number of basis points of Assets Under Management (subject to a low minimum threshold payment).

xVA

In addition to the core requirement of market risk measurement, does the CTRMS faciliate calculation of other key risk factors?  Fair-value accounting standards and (for banks) Basel III reporting requirements, may necessitate calculation of Valuation Adjustments for credit (and debit) risk (CVA and DVA), OTC funding and exchange margin funding (FVA and MVA), and the cost of holding regulatory capital (KVA).

Regulation and Compliance

The regulatory reporting requirements for commodity participants is increasingly onerous and non-compliance carries serious consequences.  Position limit monitoring (CFTC, MiFID II, as well as internally defined limits), and transaction reporting to trade repositories such as that required under MiFID II should be a non-negotiable functionality, assuming your business carries that obligation.

Process automation

What workflow automation tools does the system offer? How configurable are these, and is there a ‘no coding required’ graphical user interface provided for their creation and management? Process automation can unlock huge productivity enhancements for your staff, and avoid costly human error.

Proprietary surface and curve management

Does the system have the ability to define in-house volatility surfaces and forward curves, for the purposes of pricing deals, risk management and valuation processes. This is particularly important for products that are not exchange traded (where daily settlement prices are harder to come by), or even for London Metal Exchange options where option price settlements are not routinely published via standard market data providers.

Order management & electronic execution

For businesses with more of a paper & derivative focus, electronic execution will be increasingly important.  The vendor’s platform will almost certainly integrate with your preferred execution platform, but has that integration work been implemented already for another client, or will it need to be done for you from scratch? If so, who will pay for this? Is the frequency with which trade executions can be pushed back into the risk management system adequate?

Business Intelligence

To what extent does the CTRMS offer integrated Business Intelligence (advanced Management Information Systems) and drill-down reporting? Most will provide an API that will allow 3rd party applications (such as tableau or BusinessObjects) to run sophisticated analysis on your data, but budget-conscious firms or those with limited technical expertise will benefit from a vendor who can offer this as an integrated functionality.

Are trade entry panels configurable?

This one seems like a trivial issue, but the trade entry panels are the genesis of each deal life-cycle within the system and are possibly the most common touch-point for many users.  When it comes to esoteric OTC products many risk systems default to using a generic multi-field trade ticket. These are often cumbersome to fill out, prone to manual error, and unintuitive to the eye. If your business involves a lot of these products, look for a system that offers a high degree of configurability of deal entry panels.

Accounting functionality

A key consideration for corporate entities. Some vendors now offer hedge accounting and tax accounting functionality, so consider adding it to your requirements specification.

Data

For those of you who are putting data at the centre of your business model (see our article Data Science in Commodities), is the CTRMS architected in a way that permits easy exportation of your position and risk data to your company’s data lake for further exploitation?

Consider the security aspects of having your firm’s trade data in the cloud, assuming that you are not opting to host the vendor application yourself. What are the vendor’s security protocols?

 

 

Final thoughts

Selecting the right CTRM system for your business is a complex process. The modern CTRM system serves as the ecosystem within which all front-to-back office functions interact throughout the commodity deal life-cycle, and selecting the right system for your company is crucial for its long-term viability and growth plans.  Inside Out Advisors have gone through this process many times and are ready to assist you.