ETRMSolutionETRMSolution

Power Trading · Risk & P&L

Resolving Daily P&L Discrepancies in an ETRM Environment

A power trading desk's daily P&L report was intermittently overstating unrealized gains by a material amount, undermining the desk's confidence in the number.

Illustrative example. This case study is an anonymized composite representative of engagements we run, not a disclosure of a specific named client.

The Challenge

A mid-size power trading desk noticed that its unrealized P&L, as reported each morning, occasionally diverged from a manually reconstructed estimate by a material margin - sometimes overstating gains, sometimes understating them. The pattern was inconsistent, which made it difficult for the internal team to isolate.

Existing Environment

The desk ran on Allegro for trade capture, positions and reporting, with market data sourced from an exchange feed and a secondary broker feed used for illiquid nodes.

Root Cause

Investigation traced the discrepancy to a subset of nodes where the market data mapping fell back to a stale broker quote whenever the primary exchange feed was delayed by more than a defined threshold. The fallback logic was working as designed, but the desk was unaware it existed, and the stale quotes were sometimes materially different from the eventual settled price.

Solution

We mapped the full market data ingestion path for the affected nodes, documented every fallback and staleness rule in play, and worked with the desk to decide which nodes should use a fallback at all versus fail loudly instead. We then rebuilt the P&L attribution report to flag any valuation that used a fallback price, so the desk could see at a glance which numbers were provisional.

Investigation path

Reported P&L Discrepancy
Trade & Position Review
Market Data Path Trace
Fallback Logic Identified
Attribution Report Rebuilt
Stale-Price Flagging Added

Implementation

  • Reviewed valuation logic and market data mapping configuration node by node
  • Documented all data source fallback and staleness rules in the environment
  • Agreed revised fallback rules with the trading desk and risk team
  • Rebuilt the P&L attribution report to surface which valuations used fallback data
  • Added monitoring to alert when fallback logic was triggered

Result

  • The desk could distinguish provisional from confirmed P&L each morning
  • Fallback logic was made visible and became a deliberate, monitored decision rather than a silent default
  • Time spent manually reconciling P&L each day was substantially reduced

Technologies

AllegroSQL ServerMarket data feeds

Lessons Learned

  • Fallback and staleness logic in market data pipelines is a common, under-documented source of P&L discrepancies.
  • Making provisional valuations visible to the desk is often more valuable than eliminating them entirely.

Working through something similar?

Tell us about your environment and we'll walk through how we'd approach it.