Gravitas
Request DemoDemo
Platform Platform overview Modules Solutions Industries Commodities Roles Quant More Pricing Customers Knowledge Center Blog Company Request Demo
Knowledge Center · Guides

Cloud-native vs legacy ETRM

The architectural trade-offs that decide cost, speed, and trust, and why the difference is structural rather than a matter of features.

10 min read · Back to Guides · Data dictionary

The core difference

Legacy ETRM stitches separate trading, risk, and back-office systems together and reconciles between them. Cloud-native ETRM puts every function on one governed model, so the numbers reconcile by construction rather than by overnight batch. This one structural difference cascades into every operational property that follows.

Fragmented landscapeFront officeowncopyRiskowncopyBack officeowncopyreconciliationOne governed modelgoverneddata modelFrontRiskBackReporting
Left: every function keeps its own copy of the trade, and a reconciliation layer exists only to make the copies agree. Right: every function reads and writes one governed model, so there is nothing to reconcile.

Where the differences bite

  • Reconciliation: legacy spends its reporting effort making systems agree; modern reconciles by construction because there is one copy of each fact.
  • Timeliness: legacy values overnight; modern values in real time as trades book and prices move.
  • Change: legacy change is a development project across several systems; modern change is configuration on a shared model.
  • Integration: legacy is a silo you export from; modern is API-first.
  • Scale: legacy is sized for its peak and idle the rest of the time; modern scales elastically to the peak and releases.
Trade bookedevent logValuationPositionRisk & limitsAnalytics martsseconds,not hours
One booking emits a single event to the log; valuation, position, risk, and analytics each consume it and update within seconds. The trade is referenced, never copied.

Total cost of ownership

The headline license is rarely the real cost. Reconciliation effort, change lead time, and integration friction dominate total cost of ownership, and these are exactly where cloud-native architectures pull ahead. A complete view spans several categories, and the ones a feature comparison ignores are where the difference lives.

$$ \text{TCO} = L + I_{\text{infra}} + I_{\text{impl}} + O_{\text{ops}} + C_{\text{change}} + R_{\text{risk}} $$ The cost that matters is dominated by ops, change, and risk, not the license L

Operations cost (dominated by reconciliation), change cost, and risk cost are the terms that a governed, configurable, real-time architecture drives down, and they usually dwarf the license.

When legacy still makes sense

Honesty matters in a comparison. A legacy system that is deeply embedded, fully paid for, and adequate for a stable, narrow book may not be worth replacing today. The case for cloud-native is strongest where the book is growing or changing, where reconciliation cost is high, where real-time risk matters, or where integration and analytics are painful. The right question is not which is better in the abstract but which fits your trajectory.

Related

Guide

Selecting an ETRM

The buyer’s framework.

Whitepaper

Cloud-native ETRM

The deep version.

Guide

Modern trading architecture

Reference design.

See this on your own trades

A live walkthrough is the fastest way to connect this to your desk.

Request a demo Back to Guides