Amphora Q&A

Buying a CTRM

Straight, vendor-neutral answers to the questions every firm asks before committing budget to a CTRM: what it costs, how long it takes, how to compare vendors fairly, what to put in an RFP, and where hidden costs tend to hide.

How much does a CTRM cost?

There is no single answer, because CTRM pricing is driven by scope, deployment model and firm size rather than a fixed price list; a small single-desk trading firm and a large multi-commodity global trader can pay very different amounts for the same category of software. Total cost of ownership typically has three components: the core software licence or subscription, implementation services (configuration, data migration, integration, training and testing), and ongoing support and maintenance.

What actually drives cost is the number of users, the number of commodities and legal entities in scope, the volume and complexity of trades, how many external systems (ERP, market data, risk, treasury) the CTRM needs to integrate with, and how much configuration versus custom development the implementation requires. The most useful comparison across vendors is on a like-for-like basis, same user count, same scope, same deployment model, rather than a single headline number, which is why a detailed RFP matters more than asking any one vendor for "a price". See CTRM Commercials for how licensing and support are typically structured once you get to contract.

How long does implementation take?

Implementation timelines vary with scope, but a focused, well-defined single-commodity or single-desk implementation can typically go live within a few months of kick-off, while a large, multi-entity, multi-commodity rollout with heavy integration and data migration can take the better part of a year or more.

The biggest timeline drivers are how many integrations are needed, how much historical data must be migrated and cleaned, how many business units or geographies are in scope, and how quickly the client side can resource user acceptance testing (UAT) and reference-data sign-off. Vendors with a single-branch, highly configurable architecture generally implement faster than those requiring bespoke code changes for each client, because configuration work is lower-risk and easier to test than custom development.

How do I compare CTRM vendors?

Compare CTRM vendors on functional fit first, does the system's data model genuinely support every commodity and trade type you need, not just energy or just financials, then on architecture, single-branch versus forked codebases, cloud-native versus hosted legacy, API depth, then on delivery model, who actually implements and supports it, and only then on price.

Ask every vendor for references from clients with a similar commodity mix and trade volume to your own, and speak to at least one reference that has been live for several years, not just a recent go-live, since long-term support quality only shows up over time. A structured RFP with weighted scoring criteria keeps the comparison objective rather than driven by whichever demo looked best on the day.

What questions should I ask in a CTRM RFP?

A strong CTRM RFP covers five areas: functional fit (which commodities, trade types and workflows does the system natively support without custom code); architecture (is it single-branch or forked per client, cloud-native or on-premise, what does the API expose); implementation (typical timeline for a project of your scope, who delivers it, what does the client side need to resource); commercial terms (licensing model, what triggers additional cost, support and maintenance included versus extra); and company stability (years in business, client retention, financial health, product roadmap and release cadence).

Ask for references matching your own commodity mix and size, and ask each vendor to demonstrate the system against your own sample trades rather than a generic scripted demo, since that is what reveals genuine fit versus a polished sales pitch.

What are the hidden costs?

The costs that catch firms out are rarely the headline licence fee; they are the ones tied to how the system is actually run day to day. Common areas to probe before signing include whether upgrades are free and automatic or a separately billed project each time (forked codebases often mean every client pays again for each upgrade), how change requests and configuration changes after go-live are priced, whether integrations to ERP, market data or risk systems are included or scoped as extras, what happens to support costs as user numbers or trade volume grow, and whether historical data migration and reference-data build-out are included in the original implementation quote or billed separately once discovered.

Asking a vendor directly how their upgrade and change-request model works, before signing, is the single most reliable way to avoid surprises later.

The Amphora Difference

One branch, one price for the version you're on

Amphora runs Symphony and Alchemy on a single branch, so every client is on the same version and upgrades are free and automatic rather than a separately billed project each time, one of the hidden costs raised above.

Subscribe to the Amphora quarterly newsletter

Receive our quarterly newsletter straight to your inbox.

Subscribe