Most CTRM software will handle the book you put in front of it. What separates one platform from another is what happens afterwards: what it takes to get live, who runs it day to day, what it connects to, what it costs once everything is counted, how it copes when the book changes, and what the vendor can prove about security.
Underneath all six sits the same question. CTRM systems grew out of physical trade lifecycle management, where the design centre is the close of business and the front office was accommodated later. A trading desk evaluating one is asking whether the platform was built for the way it works, or adapted towards it.
| Criterion | What to ask the vendor for | What a weak answer sounds like |
| 1. What it was built to hold | The instruments modelled natively, and whether every commodity you trade sits in one risk view | A list of commodities covered, with instruments described as configurable |
| 2. Getting live and staying live | What has to be built before go-live, and who owns the platform afterwards | A fixed implementation timeline that does not separate construction from migration |
| 3. Integration | Which connections are part of the product and which are projects | A count of available integrations, without saying who builds them |
| 4. Cost | Everything outside the licence, including the operations time the platform will absorb | A licence figure, with implementation quoted separately and later |
| 5. Evolution | The last three changes made for an existing client, how long each took, who carried them out | A roadmap |
| 6. Security | The independent audit report, its type, its scope and the end date of the audit period | A statement that the platform is secure or enterprise grade |
Operations can already answer most of the six about the system in place today, which makes the current platform the most useful reference point available during an evaluation, and usually the last one anybody consults.
Loqsea’s CTRM alternative evaluation guide sets out how Loqsea compares against each of these criteria side by side, with a walkthrough of Risk Manager.
A data model built around cargoes, contracts and delivery carries assumptions a derivatives book does not need, and loses precision it does. Almost every system in this category either holds physical and financial together or began as an energy management platform with derivatives added afterwards, and in both cases the derivatives book is the guest.
The way to test this is to move past the commodity list. A vendor naming ten commodities has answered a question about markets. The question that matters is which instruments are modelled natively:
Where a structure is held as something approximate, the position in the system stops matching the trade on the desk, and somebody reconciles the difference by hand.
A desk running metals alongside energy tends to end up either with two systems or with one generalist platform that is shallow in both, and the exposure between them gets carried by a person with a spreadsheet.
The test Ask the vendor to model a structure from your own book rather than from their sample data. Then ask what happens where a structure is not modelled natively. Configuration means the model exists. A development request means it does not.
Loqsea was built around this question rather than adapted towards it. Coverage is commodity derivatives only, spanning metals, oil and energy, agriculture and freight in a single environment, with futures, swaps, differentials, options, warrants and LME averaging held as instrument types.
Where exchange connectivity is constructed for each client, implementation is a development project rather than a configuration exercise, and every venue added later follows the same route. Physical trade capture was never high volume, so building each connection by hand was reasonable when these platforms were designed and expensive to live with now.
Three things to establish:
Where the system is intricate enough that only a consultant understands it, the firm has taken on a dependency alongside the licence, and that dependency outlasts the implementation team.
A vendor quoting a fixed timeline is describing construction. What actually governs migration is position history and desk complexity, and the safe pattern is parallel running alongside the existing platform until the desk trusts the numbers, then cutover.
A useful question here is what the vendor’s smallest live client looks like. A platform that only performs at enterprise scale will say so in the answer, usually by describing a client much larger than the firm asking.
On the ownership question specifically, Loqsea is cloud-based, so no infrastructure is procured before go-live and no dedicated IT team is required to keep it running. Connectivity to supported venues carries no development queue. Migration timelines still depend on position history and desk complexity.
Product or project
Insufficient integration is one of the most common reasons firms replace a system, and it is rarely tested properly during selection. A CTRM platform sits between:
Each of those is either part of the product or a project. A platform that connects to venues natively and to everything else through a documented interface behaves very differently from one where each link is scoped, quoted and queued.
Trade capture deserves specific attention, because it is where the front office meets the system most often. Electronic execution is the straightforward case. What happens to a trade agreed by phone, a broker fill or an OTC structure determines whether the risk view is complete or merely mostly complete, and a platform that cannot take those trades cleanly pushes them into a spreadsheet nobody upstream can see. Worth asking how each route enters the system, and whether a trade agreed by phone reaches the risk view at the same speed as one executed on screen.
Loqsea connects to major exchanges including ICE, CME, LME and SGX. Trades are captured as they execute, through Trading Technologies (TT) and clearing brokers, and voice and OTC trades are captured through the blotter, so the whole book sits in the same risk view regardless of how each trade was agreed.
Implementation, data migration, integrations, training, ongoing administration and add-ons routinely account for the majority of total spend across enterprise software, and CTRM is not an exception.
Worth establishing in writing:
Beyond all of that sits the operations time absorbed by whatever the system cannot close. Manual verification scales with trade count, so a desk doubling its activity doubles those hours, and the response is usually another pair of hands rather than a conversation with the vendor. That cost lands in the operations budget instead of the technology budget, which is why it rarely appears in the first-year review of the platform that caused it.
Worth quantifying before you sign Count the hours your team currently spends each week on work that exists only because the system cannot close a loop. That figure is part of the price of the platform you have, and it belongs in the comparison against the ones you are evaluating.
With Loqsea there is no infrastructure to procure or maintain, no dedicated IT resource required, and no minimum trade volume, so the costs that usually sit outside the licence do not accumulate in the same way.
Every evaluation is run against the book the desk trades today. A trader joins with a strategy behind them, liquidity moves to another venue, a client asks for a structure the desk has not run before.
The most revealing question a vendor can be asked is what the last three changes made for an existing client were, how long each took and who carried them out.
The same logic applies to adding a venue or an instrument. Configuration means the model already exists and the desk is switching it on. A development request means joining a queue, and the timeline belongs to the vendor’s release cycle rather than to the trading calendar. Platforms built around a settlement cycle tend to change on one as well.
Vendors describe their security in similar language, so the distinction worth drawing out is what has been independently verified. A SOC 2 Type II report covers whether controls operated effectively across a period. A Type I report describes how they were designed at a single point in time.
Ask for:
A fund answering an allocator’s due diligence questionnaire will be asked about its risk system, and a vendor with no report to produce turns that into the firm’s problem.
On this criterion Loqsea has been independently audited to SOC 2 Type II, and the report is available on request.
Taken together, the six describe how a platform behaves rather than what it contains, which is the part a feature comparison cannot reach. Most of them can be answered about the current system before a single vendor is contacted, and the answers make a far sharper requirements document than a list of screens.
They also tend to resolve to the same thing. A platform designed around the close of business behaves like one, whatever has been added since, and a desk that needs the position now will feel the difference every day it uses it.
Loqsea was built for the front office and works outward from there, which is why it answers these six the way it does. The evaluation guide sets out each one side by side against what most platforms offer.
See how Loqsea compares against all six criteria or book a demo on your own book.
