Pre-Trade Data: The Missing Layer in Many Trading Architectures

When trading technology architecture gets diagrammed, most of the attention goes to the ETRM itself and what happens after a trade is captured. What often gets skipped over - despite being where a large share of downstream problems originate - is the layer that sits before any of that: pre-trade data.

What we mean by pre-trade data

Pre-trade data is everything that needs to reach your trading and risk ecosystem before or independent of a specific trade: market prices, forward curves, volatility surfaces, weather and fundamentals data, reference data like counterparties and calendars. It's the raw material that valuation, risk and even trading decisions are built on.

The common architectural gap

In a surprising number of environments we've reviewed, this data flows directly from an external provider's API or file feed straight into the ETRM, with little or no independent validation, normalization or reconciliation layer in between. The ETRM becomes, by default, the place where bad data first gets noticed - usually because it shows up as a wrong valuation or a missing price, well after the actual problem occurred upstream.

What a proper pre-trade data layer looks like

The point of this layer isn't complexity for its own sake - it's separating concerns. The ETRM should be able to trust that the data it receives has already been validated and normalized, rather than needing to defensively second-guess every incoming price. And when something does go wrong, having a dedicated layer means you can trace exactly where in the pipeline - source, ingestion, validation, mapping - the problem was introduced.

Why this gets skipped

Most trading businesses don't set out to skip this layer - it accumulates by omission. A direct feed gets connected as a quick fix under time pressure, works fine for months, and becomes permanent infrastructure by default. By the time the gaps show up, the direct connection is deeply embedded and harder to unwind than it would have been to build correctly from the start.

A practical starting point

You don't need to rebuild your entire data architecture at once. The highest-leverage starting point is usually identifying your two or three most business-critical data sources - the ones that, if wrong, would most directly damage P&L or risk decisions - and building a proper validation and normalization layer around those first.