Why Market Data Quality Matters in Commodity Trading

A surprising share of the ETRM issues that get reported as application bugs - wrong P&L, unreliable risk numbers, valuations that don't make sense - actually trace back to market data quality problems, not application logic. The ETRM is often just the messenger reporting the consequences of data that was already wrong before it arrived.

What "market data quality" actually covers

Data quality isn't a single property. In a trading context it typically breaks down into:

• Completeness - is every price you expect actually present, with no silent gaps
• Accuracy - does the price match what actually traded or was quoted in the market
• Timeliness - did the data arrive in time to be used for the decision it's meant to support
• Consistency - do related instruments (e.g. a curve's individual points) move in economically sensible relation to each other
• Provenance - do you know exactly which source, and which fallback logic if any, produced a given value

Why bad data is expensive

A single bad price feeding into a valuation can misstate P&L, distort a risk report, or - in the worst case - influence a trading decision made on the strength of a number that was never real. Because market data feeds into nearly every downstream calculation, a data quality problem doesn't stay contained to one report; it propagates into P&L, risk, and often settlement.

Where data quality problems typically originate

In our experience investigating these issues, the root cause is rarely a dramatic failure. It's usually one of a few quiet, structural gaps:

• Manual data entry or file uploads with no automated validation step
• Fallback or default logic (using a stale price when a feed is delayed) that nobody documented or is even aware exists
• Reference data mismatches - the same instrument named slightly differently across two systems
• No monitoring to detect when a feed silently stops updating, as opposed to erroring loudly

What a mature data quality process looks like

The businesses that don't get burned by data quality issues typically have validation built into the pipeline itself, not layered on as a manual afterthought: bounds and range checks, day-over-day change thresholds, cross-source comparison where multiple providers quote the same instrument, and clear, visible flagging whenever a fallback or default value is used rather than a genuine market observation.