Data Architecture for Enterprise ETRM

Executive summary

Every capability an ETRM platform offers, trade capture, position management, risk, scheduling, settlement, compliance, analytics, is ultimately a function of its data. If the underlying data model is fragmented, inconsistent, or duplicated across systems, every capability inherits those flaws. If it is unified, governed, and coherent, every capability builds on solid ground. Data architecture, in other words, is not a technical detail beneath the platform; it is the platform.

This is the theme that runs through the entire Gravitas approach, and this article makes it explicit. It sets out what a sound enterprise ETRM data architecture looks like: a canonical domain model that represents trades, positions, reference data, market data, operations, and settlement as one coherent whole, rather than a patchwork of overlapping databases stitched together by reconciliation.

It covers why data architecture matters, the core design principles, the enterprise domain model, and the architecture of reference data, trade capture, market data, position and risk, physical operations, settlement, and the analytics and AI layer. It opens the data cluster and connects to master data management, data governance, and the modern ETRM guide.

Why data architecture matters

The cost of poor data architecture is paid every day, in reconciliation between systems that disagree, in numbers that cannot be trusted without checking, in the slow, error-prone hand-offs that fragmentation forces. When trade data lives in one system, positions in another, and risk in a third, keeping them consistent becomes a permanent tax on the operation, and the answer to "what is our position?" depends on which system you ask.

A sound data architecture removes that tax at the root. When there is one authoritative representation of each trade, position, and reference entity, every function reads and writes the same truth, and the reconciliation, latency, and ambiguity that fragmentation creates simply do not arise. This is why data architecture is the highest-leverage decision in an ETRM platform: it determines whether every downstream capability is built on consistency or on the constant effort of papering over inconsistency.

Core design principles

A strong ETRM data architecture rests on a handful of principles that, applied together, produce coherence.

The unifying idea is that data should be modelled once, authoritatively, and consumed everywhere, rather than copied and re-interpreted by each system. When these principles hold, the platform has a spine, a canonical model that everything else attaches to, and that spine is what makes consistency the default rather than an achievement. The sections that follow trace this spine through each domain of the platform.

The enterprise domain model

At the centre of the architecture is the domain model: the set of core entities the whole platform is built around, and the relationships between them. In an ETRM these entities are well understood, and modelling them coherently is the foundation.

The critical design choice is that these domains share one model rather than living in separate systems with their own copies. A trade references governed reference data; a position derives from trades and market data; a settlement derives from a trade and its deliveries. When these relationships are modelled explicitly on one canonical model, the platform can answer any question, from a single trade to the whole book, by traversing one coherent structure, which is exactly what fragmented architectures cannot do.

Reference data architecture

Reference data, the masters for commodities, instruments, locations, calendars, and counterparties, is the foundation everything else references, so its architecture matters disproportionately. Reference data must be governed, versioned, and authoritative, because an error or inconsistency here propagates into every trade, position, and report that uses it.

The right approach is a governed reference-data platform with controlled change, so that a new commodity, a revised calendar, or an updated counterparty is created and approved once and consumed consistently everywhere. This is significant enough to be its own discipline, explored in master data management. The architectural point here is that reference data is not scattered lookup tables but a first-class, governed layer that the transactional model depends on, which is what keeps the whole platform internally consistent.

Trade capture data model

The trade is the central transactional entity, and its data model has to be expressive enough to represent the full variety of physical and financial energy trades, from a simple forward to a complex structured deal, while remaining canonical. A trade captured once, faithfully, becomes the single record that valuation, risk, scheduling, and settlement all read.

The design principle is that the trade model captures economic reality precisely, its legs, pricing, delivery, and optionality, and references governed reference data rather than embedding copies of it. This is the data-architecture face of trade capture: when the trade is modelled canonically and captured once, everything downstream is consistent by construction, and the question of whether trading, risk, and settlement agree about a trade never arises, because they are all reading the same record.

Market data architecture

Market data, prices, curves, volatilities, and fixings, is the other major input to valuation and risk, and its architecture must be governed and consistent for the same reasons as reference data. A position valued against one version of a curve and reported against another is a reconciliation waiting to happen.

The architecture should treat market data as a governed, versioned layer with clear lineage, so that every valuation and risk number can be traced to the exact market data that produced it. This is the foundation of a modern market-data platform and forward curve construction. When market data lives on the same governed foundation as trades and positions, valuation is consistent across the platform, and the pricing-to-trading reconciliation that plagues fragmented systems largely disappears.

Position and risk data

Positions and risk are derived data: a position is computed from trades and market data, and risk measures are computed from positions. The architectural requirement is that these derivations are consistent, live, and traceable, so the position and risk the desk sees always reflect the current trades and market data.

Because position and risk are derived, their integrity depends entirely on the integrity of the trade and market-data layers beneath them, which is exactly why a canonical model matters. When positions derive from one authoritative trade record and one governed market-data layer, real-time position management and risk are consistent by construction, and every risk number, from VaR to a single exposure, can be traced back to the trades and prices that produced it. Derived data is only as trustworthy as its sources, and the canonical model is what makes the sources trustworthy.

Physical operations data

Physical energy trading adds an operational layer, schedules, nominations, deliveries, inventory, that must connect coherently to the trades it fulfils. A schedule realises a trade; a delivery updates an inventory position; a nomination reflects a contractual commitment, and these relationships have to be explicit in the model.

The architectural challenge is that operations data is both voluminous and tightly coupled to trades, so it must sit on the same canonical model rather than in a separate operational system. When scheduling, storage, and inventory all reference the same trades and positions as the front and middle office, the physical and financial views of the business stay synchronised, and the operation can see, on one model, both what it has traded and what it has physically delivered.

Settlement and finance data

Settlement is where trading meets money, and its data must tie cleanly back to the trades and deliveries it settles and out to the finance systems it feeds. An invoice derives from a trade and its measured delivery; a payment settles that invoice; a reconciliation confirms it, and each of these must trace to its source.

The architectural requirement is that settlement derives from the same canonical trade and operations model, so invoices and payments are consistent with the trades they settle, and integrates cleanly with finance and ERP systems downstream. This is the data-architecture underpinning of confirmations and settlements and ERP integration. When settlement reads the canonical model, the numbers that reach finance tie out against trading, which is what makes the month-end close clean rather than a reconciliation marathon.

The AI and analytics layer

Analytics and AI sit on top of the transactional model, and their reliability depends entirely on the quality of the data beneath them. The architecture should provide a clean analytical layer, marts and lineage, derived from the canonical model, on which reporting, dashboards, and AI can operate.

The decisive principle is separation with lineage: the analytical layer is derived from the authoritative transactional model, not a disconnected copy, and every analytical output can be traced back through it to source. This is what makes dashboards, analytics platforms, and AI trustworthy: they reason over a governed derivation of one authoritative model rather than over ungoverned copies. As the whole AI cluster argues, the intelligence is only as good as the data foundation, and this is that foundation.

Why the Gravitas canonical data model is different

Gravitas is built on one canonical data model that every function reads and writes.

Because everything attaches to one canonical spine, consistency is the default and reconciliation the exception, which is what makes every downstream capability trustworthy. And it is delivered at economics that suit desks the incumbents priced out. See the platform, who Gravitas is for, or request a demo.

Implementation best practices

Building a sound ETRM data architecture rests on a few principles. Model each core entity once, authoritatively, and consume it everywhere rather than copying it. Treat reference and market data as governed, versioned layers with lineage. Derive positions, risk, and settlement from the canonical model so they are consistent by construction. Keep operations on the same model as the front and middle office. And build the analytical and AI layer as a lineage-tracked derivation of the transactional model, not a disconnected copy.

The through-line is that a canonical data model is the highest-leverage investment in an ETRM platform, because every capability is a function of the data beneath it. Get the architecture right and consistency is free; get it wrong and every capability carries the permanent cost of reconciling systems that were never designed to agree.

Architecture KPIs

An ETRM data architecture can be measured across consistency, traceability, and efficiency.

Consistency and reconciliation effort measure whether the canonical model is holding; lineage and traceability measure whether numbers are defensible; settlement tie-out and analytical latency measure whether the architecture pays off downstream. Together they describe a platform built on a spine rather than a patchwork.