What is ETRM & CTRM?

The distinction is scope, not architecture. ETRM historically refers to energy commodities, power, natural gas, crude oil, refined products, and LNG. CTRM extends to the broader commodity complex, including agriculture, metals, and softs. In practice the terms are used interchangeably, and a modern platform such as Gravitas spans both on a single data model.

What makes these systems distinct from generic trading software is that commodities are physical. A barrel of oil or a megawatt-hour of power has to be scheduled, delivered, and reconciled, not just bought and sold on an exchange. An ETRM/CTRM has to handle both the financial and the physical sides of the same trade.

Every ETRM/CTRM is organized around the journey a trade takes from the moment it is agreed to the moment cash changes hands. Understanding this lifecycle is the key to understanding the software:

• Capture, the trade is booked with its economic terms: instrument, quantity, price, delivery, and counterparty. See the Trade Capture module.
• Valuation, the position is marked to market against current prices and forward curves. See Valuation.
• Risk, exposure is measured with metrics like Value at Risk and the Greeks. See Risk.
• Scheduling, for physical trades, volumes are nominated and delivery is coordinated. See Scheduling.
• Settlement, invoices are generated, matched, and settled to cash. See Settlements.
• Reporting, position, P&L, and regulatory reports are produced from the same governed data. See Reporting.

Because the lifecycle has distinct stages, ETRM/CTRM platforms are typically modular. Each module is a first-class capability, but the value comes from them sharing one data model so a trade captured once flows through every downstream function without re-keying. That single-model design is what lets position, P&L, and risk numbers reconcile with the front and back office instead of diverging across disconnected systems.

On top of the operational modules, a modern platform adds an analytical layer, a BI & OLAP mart warehouse, that turns the trading data into query-ready star schemas for business intelligence tools.

A recurring theme in commodity trading is the split between physical and financial. A physical trade results in actual delivery, gas flowing through a pipeline, power on a grid, a cargo of crude on a vessel. A financial trade (a future, option, or swap) settles in cash against a reference price and never results in delivery.

Desks use both: financial instruments to hedge price risk and physical deals to meet real supply obligations. An ETRM/CTRM has to value and risk-manage them together, because the net exposure that matters is the combination of the two.

A single governed model represents both kinds of trade the same way, so a net position is a query, not a reconciliation across two systems:

python# Physical and financial positions net on one governed model.
def net_position(book, commodity, location, bucket):
    legs = trades.query(book=book, commodity=commodity,
                        location=location, bucket=bucket)
    physical = sum(l.signed_quantity for l in legs if l.is_physical)
    financial = sum(l.delta_equivalent for l in legs if not l.is_physical)
    return physical + financial      # one number, one source of truth

When comparing platforms, the questions that separate a modern system from a legacy one are architectural:

• One data model or many? If trade, risk, and settlement live in separate databases, every report is a reconciliation.
• Real-time or overnight? Legacy systems often value and risk positions in nightly batches. Modern platforms do it against live prices.
• API-first or closed? A governed API lets the platform integrate with market data, ERP, and downstream systems instead of becoming another silo.
• Configurable or coded? New commodities and reports should be configuration, not a development project.
• Cloud-native or on-premise-only? Deployment flexibility affects cost, scale, and time to value.

These themes are explored further in The future of ETRM.