Skip to main content

43. Exchange as PnL Source of Truth

Status: Accepted Date: 2025-07-06

Context​

In any trading system, calculating Profit and Loss (PnL) is a fundamental requirement. We need to decide on the definitive source of data for these calculations. The system could rely on its own internal record of trades (order placements, assumed fills) or it could rely on the data reported directly by the exchange. Using internal data is faster but can drift from reality due to missed fills, unexpected fees, or partial executions. The exchange's data is the ultimate source of truth but can be slower to access.

Decision​

All official, final PnL calculations for reporting, settlement, and performance analysis must use data fetched directly from the exchange as the source of truth. The system's internal records of trades should be considered a non-authoritative cache or a real-time estimate. For any process where accuracy is paramount, the system must reconcile its state with the exchange's reported fills, fees, and positions.

Consequences​

Positive:

  • Accuracy: The calculated PnL will accurately reflect the real-world performance of the trading strategies, including all fees and execution nuances.
  • Reliability: This eliminates the risk of "state drift" where the system's internal view of its positions and PnL diverges from the reality on the exchange.
  • Simpler Reconciliation: The reconciliation process is simplified: the exchange's data is always correct, and the internal system state must be updated to match it.

Negative:

  • Latency: Fetching data from the exchange is slower than accessing internal records. Real-time PnL estimates will have higher latency.
  • API Dependency: The system becomes more dependent on the availability and reliability of the exchange's API for a core function.
  • Increased Complexity: The system must include robust logic to fetch, parse, and handle data from the exchange's API, including handling rate limits and errors.

Mitigation:

  • Hybrid Approach for Real-Time Data: For high-frequency, real-time displays (e.g., on a dashboard), it is acceptable to use internal calculations for an estimated PnL, with the clear understanding that it is an estimate. This real-time estimate should be periodically updated with authoritative data from the exchange.
  • Resilient API Client: The service responsible for fetching data from the exchange (e.g., Hermes) must be built with resilience in mind, including features like exponential backoff, rate limit handling, and circuit breakers.
  • Asynchronous Updates: Authoritative PnL calculations can be performed by an asynchronous background job, which fetches data from the exchange and updates the system's database without blocking the main trading logic.