Why Pricing and Position Must Share One Data Model
The reconciliation breaks that erode desk confidence in CTRM output originate in a structural gap: two systems modeling the same physical and financial reality using independent representations. The pricing-position gap in CTRM cannot be closed by integration. Only a shared data model eliminates this break class entirely, because it eliminates the architectural conditions that produce the breaks in the first place.
This is the architectural argument for why Novaex Pulse and Novaex Ledger operate on a single underlying data model as the only engineering response to a specific class of reconciliation failures that have cost metals desks millions in manual remediation hours and, worse, in decisions made on positions that were quietly wrong.
The Specific Class of Breaks That Live in the Pricing-Position Gap
Most CTRM reconciliation failures are diagnosed as data quality problems. The upstream feed was late. The settlement price was not loaded. The trader entered the wrong lots. These are solvable with better operations.
The break class this post addresses is different. These breaks occur when both systems are operating correctly, with identical upstream data, and they still disagree. According to a 2023 industry benchmark report by Commodity Technology Advisory (ComTech Advisory), 67% of CTRM users report recurring reconciliation discrepancies they classify as unexplained: breaks that survive data cleanup and persist through system upgrades.
These breaks survive because their root cause is model divergence: two systems built to price or position independently, then connected at the seam, develop structural disagreements about the same underlying reality.
The specific break types that originate in the pricing-position gap include:
- MTM basis breaks: pricing and position systems applying different interpolation methods to the same forward curve, producing MTM valuations that diverge by basis points compounding across large books
- Prompt date misalignment breaks: pricing engines working on LME prompt date logic disagreeing with position systems working on calendar date logic, producing phantom open positions on settlement days
- Delta aggregation breaks: hedge ratios calculated from an options pricer that uses a separate vol surface from the one stored in the position system, making delta-hedged books appear unhedged
- Carry cost breaks: financing rates used in pricing that differ from the rates embedded in the position system's cost-of-carry model, producing P&L attribution errors on any position held overnight
- Settlement price override breaks: when official settlement prices replace estimated prices at end-of-day, pricing and position systems applying the override in different sequences, producing a window of disagreement that sometimes closes and sometimes does not
- Lot size normalization breaks: COMEX and LME contract specifications handled differently in pricing versus position, causing exposure calculations to diverge on cross-exchange hedge books
- FX conversion timing breaks: currency conversion applied at different points in the valuation chain, producing MTM in USD that disagrees by the exact magnitude of the intraday FX move
The Root Cause of MTM Reconciliation Breaks in CTRM Systems
MTM reconciliation breaks in CTRM systems are caused by model divergence. When a pricing engine and a position engine maintain independent representations of the forward curve (even when sourcing from the same upstream feed), small differences in interpolation method, day count convention, or discount rate basis compound across a book into breaks that appear unexplained. The root cause is structural: two models cannot represent the same curve identically unless they share the same model.
According to ComTech Advisory CTRM benchmark research, fewer than 20% of commodity trading operations can close their daily MTM reconciliation in under one hour. The remaining 80% absorb manual remediation labor that should not exist.
Why Integration Is Architecturally Insufficient to Close the Pricing-Position Gap
The standard response to the pricing-position gap is integration: an API, a shared database table, a nightly synchronization job, or a middleware layer that moves data between systems. This response is understandable. It preserves existing vendor investments. It is the path of least operational disruption.
It is also architecturally incapable of solving the break class described above.
Integration moves data between two independent models. It does not make those models the same. When Pricing System A sends a forward curve to Position System B via API, System B receives a discrete set of numbers. It does not receive the interpolation logic, the day count convention, the prompt date calendar, or the discount basis that System A used to construct those numbers. System B must reconstruct the curve using its own logic, and it will do so differently.
The Limits of Middleware Integration for Pricing-Position Breaks
Middleware integration cannot eliminate pricing-position breaks because it focuses solely on data transport. Even a perfectly executed integration that delivers identical source data to both systems leaves both systems free to interpret that data differently. The breaks that originate in the pricing-position gap are not data transport problems; they are model divergence problems, and they require a model-level solution.
This is not a theoretical objection. The metals trading desks that have invested most heavily in integration infrastructure (custom middleware, real-time API connections, shared reference data repositories) still report the same structural break categories. A 2022 Accenture study on commodity trading operations found that firms spending over $2M annually on CTRM integration reported no statistically significant reduction in daily reconciliation break frequency compared to firms with lighter integration footprints.
The integration approach also creates a second-order problem: latency asymmetry. In a fast market (LME aluminum moving 2% intraday, COMEX copper printing through technical levels), the pricing system and position system update on different schedules. The pricing system may update in milliseconds from a market data feed. The position system may update in minutes from an integration batch. For the duration of that lag, the desk operates with a position that is priced correctly in one system and incorrectly in another. That latency gap is not an integration performance problem. It is a structural consequence of running two systems.
The Prompt Date Problem Is More Dangerous Than It Looks
Prompt date logic deserves specific attention because it produces the most operationally damaging break type in the pricing-position gap, and it is the least visible until it matters most.
LME pricing operates on a prompt date calendar: a specific set of business days on which contracts settle, governed by LME rules, bank holidays, and ring session schedules. This calendar is not equivalent to a generic business day calendar. It differs from COMEX settlement logic, from SHFE settlement logic, and from the calendar most position systems were built to use.
When a pricing engine has been built specifically for LME base metals, it encodes this prompt date logic natively. Every forward point, every interpolated rate, every option expiry is anchored to a prompt date the LME recognizes. According to LME published trading data, there are approximately 252 LME trading days per year, but prompt date settlement obligations for specific contracts fall on dates that a calendar-day position system may not recognize as settlement events.
How Prompt Date Breaks Create Phantom Positions
Prompt date breaks create phantom positions because a position system using calendar date logic will calculate open exposure on days the LME has already settled. If a three-month copper position settles on a specific LME prompt date and the position system does not recognize that prompt as a settlement event, the position remains open in the system after it has closed in the market. The trader's risk report shows exposure that does not exist, and any hedging decision made on that report is made against a position that has already been unwound.
This break type carries the greatest operational risk for basis positions and calendar spreads, where prompt date precision determines whether a spread is on-prompt or off-prompt. This distinction carries significant liquidity and pricing implications on the LME ring. A position system that cannot resolve prompt date logic correctly will misclassify spread legs, produce incorrect carry cost calculations, and generate hedge recommendations that are directionally wrong.
The only structural solution is to run pricing and position on a single prompt date calendar that both systems reference natively.
What a Shared Data Model Actually Means in Practice
A shared data model means that pricing logic and position logic operate on the same internal representation of every financial object: every curve, every position, every contract specification, every calendar event.
In practice, this requires four specific architectural commitments:
- A single forward curve object that both pricing and position read without transformation. The interpolation method is defined once. The day count convention is defined once. The discount basis is defined once. When the curve updates, both systems see the identical update instantaneously since there is only one shared curve.
- A single contract specification library that encodes LME, COMEX, MCX, and SHFE contract specifications (lot sizes, tick sizes, settlement methods, delivery grades) in a form that both pricing and position consume without translation. A COMEX copper lot is 25,000 lbs in one place, ensuring absolute consistency across the entire architecture.
- A single prompt date calendar that governs both when contracts settle in the pricing model and when exposure closes in the position model. The pricing engine and position engine agree on settlement timing because they function as two views into the same model.
- A single valuation timestamp applied to every MTM calculation, so that pricing and position are never measured at different points in time. Latency asymmetry cannot exist when there is one calculation event.
Defining a Shared Data Model in Commodity Trading Systems
A shared data model in commodity trading systems is an architecture in which the pricing engine and position engine reference a single internal representation of every financial object (curves, contracts, calendars, and positions) rather than maintaining independent representations that must be synchronized. Synchronization preserves the conditions for model divergence; shared representation eliminates those conditions structurally.
This architecture requires that pricing intelligence and position management be built as a unified system from the start. According to Gartner research on financial services data architecture, organizations that migrate from federated to shared data models report a 40, 60% reduction in reconciliation labor within 18 months. In commodity trading, where reconciliation labor concentrates in high-volatility periods (exactly when it can least afford to consume trader attention), that reduction has direct operational value.
How Novaex Pulse and Novaex Ledger Implement Shared Data Model Architecture
Novaex Pulse is the pricing intelligence layer: LME, COMEX, MCX, and SHFE forward curves, options surfaces, settlement prices, and derived analytics for base metals. Novaex Ledger is the position management layer: physical and financial positions, hedge book management, P&L attribution, and exposure reporting.
They share one data model through fundamental architecture.
Every forward curve that Pulse constructs is the same curve object that Ledger uses to value open positions. When Pulse updates the LME copper three-month forward on an intraday basis point move, Ledger's MTM updates on the same object. There is no synchronization event. There is no latency window. There is no translation layer where a discrete set of numbers crosses from one model into another.
The prompt date calendar that Pulse uses to price LME contracts is the same calendar that Ledger uses to determine when positions settle. A three-month aluminum contract that Pulse prices against a specific LME prompt is the same contract object that Ledger tracks as open until that exact prompt date. There is no phantom position class because there is no prompt date divergence.
The vol surface that Pulse uses to calculate delta on an LME copper options position is the same surface that Ledger uses to report that book's delta exposure. A delta-neutral book in Pulse is a delta-neutral book in Ledger since both surfaces read the same calculation result.
This is why the seven break types described in this post do not occur in the Novaex architecture, as the structural conditions that produce them simply do not exist. Novaex platform architecture overview
The Operational Cost of the Pricing-Position Gap
The reconciliation breaks that originate in the pricing-position gap carry a measurable operational cost that extends well beyond the hours spent investigating them.
Desk confidence degradation is the primary cost. When a trader has experienced enough MTM breaks, prompt date phantom positions, and delta mismatches, they stop trusting system output. According to a 2023 EY survey of commodity trading operations, 43% of front-office traders reported maintaining at least one Excel-based shadow position tracker because they did not trust their CTRM's position output. That shadow infrastructure is the direct cost of the pricing-position gap: it consumes trader time, introduces new error surfaces, and degrades precisely the operational speed that modern metals desks require.
Decision latency is the second cost. In LME base metals trading, where three-month spreads can move 15, 20 basis points in a session and physical premiums can gap on supply news, the window for a hedging decision is measured in minutes. A trader who must reconcile system output against a shadow spreadsheet before acting has already missed that window. The pricing-position gap creates structural decision latency that is indistinguishable in its effect from being slow.
Audit and compliance exposure is the third cost. When a pricing system and position system produce different valuations for the same book, the question of which valuation is authoritative does not have a clean answer. Regulatory reporting, counterparty margin calls, and internal risk limits that reference a position number disagreeing with the pricing number represent a compliance exposure that grows with book size and volatility. A shared data model produces one number, which is the authoritative number, with one audit trail.
The Impact of the Pricing-Position Gap on Hedge Effectiveness Reporting
The pricing-position gap directly undermines hedge effectiveness reporting because IAS 39 and IFRS 9 hedge accounting require that the hedging instrument and the hedged item be valued using consistent methodologies. When the pricing system and the position system apply different valuation logic (different interpolation, different discount rates, different settlement dates), the effectiveness ratio they produce is not comparable. Auditors examining hedge documentation from a CTRM architecture with separated pricing and position engines will find effectiveness ratios computed from inconsistent inputs, creating a documentation deficiency that can disqualify hedge accounting treatment entirely.
The Gap Cannot Be Bridged, Only Eliminated
The seven break types described in this post (MTM basis breaks, prompt date misalignment, delta aggregation failures, carry cost divergence, settlement price override sequencing, lot size normalization errors, and FX conversion timing breaks) share one structural cause. They occur when a pricing model and a position model maintain independent representations of the same financial reality.
This cause cannot be addressed by better integration, faster synchronization, or more sophisticated middleware. Those approaches improve data transport between two models. They do not make the models the same. Only a shared data model architecture eliminates the break class, because only shared architecture eliminates the conditions that produce the breaks.
Three actions to assess your current architecture right now:
- Run a prompt date audit. Pull your LME position system's open positions at end-of-day on an LME settlement date and compare against your pricing system's settled contracts. Phantom positions on dates your pricing system shows as settled are direct evidence of prompt date divergence.
- Stress-test your delta consistency. Take a delta-neutral options book as reported by your pricing system and pull the same book's delta from your position system. If the numbers disagree by more than rounding error, your systems are running different vol surfaces.
- Measure your reconciliation window. Time how long middle office requires to close daily MTM reconciliation between your pricing system and position system. If it exceeds 30 minutes, you have a structural architecture problem.
If your current infrastructure produces any of the break types described above, the path forward requires a different architecture. Schedule a technical architecture review with the Novaex team