Metals Position Reconciliation: Inside the Single Book
TL;DR: Metals trading position reconciliation across physical contracts, futures hedges, and options requires shared instrument identifiers, delivery-period alignment, and delta-equivalent normalization, not manual export aggregation. Novaex Ledger performs this at the data-field level, linking OFFSET_CONTRACT_ID references across the Physical Book and Derivatives Desk modules to produce one reconciled position view without manual aggregation steps.
The most direct drain on metals trading desk efficiency is the period before risk reporting when position data from disconnected systems produces contradictory net exposure figures. This recurring discrepancy demands manual resolution precisely when market conditions require trader attention elsewhere.
According to a 2023 Accenture survey of commodity trading organizations, 68% of front-office traders spend more than 90 minutes per day reconciling position data across disconnected systems. This figure represents a structural failure that compounds when markets move fastest.
The root cause is architectural. Most CTRM platforms store physical contracts, exchange-traded futures, and options in separate modules with incompatible data schemas. Exporting each, aligning delivery periods manually, converting options to delta-equivalents in a spreadsheet, and summing net exposure is reconstruction. These tasks belong in the system architecture, not in the daily workflow of a trading desk.
This post explains how Novaex Ledger resolves that structural failure through a single book that ingests all three position types, maps them through shared field references, and delivers a reconciled metals trading position view without requiring manual aggregation across system exports.
Why Metals Position Reconciliation Breaks Without a Shared Data Schema
Fragmentation in metals position management is fundamentally a data architecture problem.
A physical copper contract carries fields that a futures system does not recognize: METAL_GRADE, ASSAY_RESULT, PORT_OF_LOADING, INCOTERM, PRICING_DATE windows, and provisional/final invoice settlement flags. A futures position carries fields that a physical module does not track: PROMPT_DATE, LOT_SIZE, MARGIN_REQ, and EXCHANGE_CODE designations across LME, COMEX, MCX, or SHFE. An options book adds STRIKE_PRICE, EXPIRY_DATE, OPTION_TYPE (vanilla, Asian, barrier), and Greeks that require daily recalculation against mark-to-market curves.
When these three schemas live in separate modules with no shared key, every position view becomes a reconciliation exercise. The system imposes this burden directly on the trading desk.
What Causes Position Discrepancies Between Physical and Derivatives Books?
Position discrepancies between physical and derivatives books arise when delivery periods in the physical module do not map to prompt dates in the futures module on the same time axis. A physical contract priced against the LME third Wednesday of a given month will show a different exposure date than a futures lot carrying that exact prompt date, unless both records resolve to the same DELIVERY_PERIOD reference. Most legacy CTRM platforms leave this alignment to the user, creating a persistent gap between what the risk system reports and what the book actually holds.
LME prompt date structure and physical pricing basis
According to a 2022 Energy Risk report, commodity trading firms lose an average of $2.3 million annually in operational risk events directly attributable to position data mismatches (administrative failures rather than market moves). In base metals, where LME prompt structures create daily price exposure against open quotational periods, that figure understates the actual cost.
Novaex Ledger addresses this at the schema level. Every position record, whether physical, futures, or options, carries a DELIVERY_PERIOD field that resolves to the same exchange-defined calendar reference before it enters the reconciled book. There is no post-entry alignment step because the alignment is enforced at data entry.
How Ledger's Single Book Captures Physical Contract Data
The Physical Book module in Novaex Ledger captures a metals purchase or sale contract against a structured field schema that becomes the anchor for all downstream reconciliation.
A physical copper purchase committed to the Physical Book module populates the following fields: CONTRACT_ID (system-generated unique key), COUNTERPARTY_ID (linked to the counterparty master), METAL_GRADE (e.g., CU-CATH-A for LME Grade A cathode), QUANTITY_MT (metric tons), PRICING_DATE (window start and end for quotational period pricing), PRICE_BASIS (LME cash, LME 3M, COMEX nearby), INCOTERM (CIF, FOB, DDP), PORT_OF_LOADING, and DELIVERY_PERIOD (resolved to the LME monthly prompt window for hedging alignment).
The DELIVERY_PERIOD field is the critical join key. Instead of a free-text date field, it resolves to an exchange-defined period code. For LME, this maps to the third-Wednesday prompt structure. This field resolution is what allows the Physical Book module to handshake with the Derivatives Desk module without requiring a translation layer between the two.
What Data Fields Are Needed to Track a Physical Metals Contract?
Tracking a physical metals contract with the precision required for hedging and mark-to-market valuation requires at minimum: a unique CONTRACT_ID, a DELIVERY_PERIOD resolved to exchange prompt structure, QUANTITY_MT in standardized units, PRICE_BASIS referencing a specific exchange benchmark, and a PRICING_DATE window that defines the quotational period for MTM exposure. Without all five fields populated consistently, the contract cannot be correctly hedged, valued, or reconciled against derivatives positions in a unified book.
Novaex Ledger enforces these fields at data entry. Contracts missing PRICE_BASIS or PRICING_DATE cannot be committed to the Physical Book module. They are flagged as incomplete and held in a pre-commitment queue with the specific missing field identified.
physical contract data schema for base metals CTRM
According to the International Energy Agency's 2023 commodities market report, base metals physical trading volumes increased 14% year-over-year, with copper and aluminum accounting for the largest share of new OTC physical positions. As volume grows, the cost of incomplete physical data fields scales proportionally: each uncommitted contract represents unhedged exposure.
Once a physical contract is committed, Ledger calculates the open pricing exposure, the quantity still subject to price moves within the PRICING_DATE window. This value feeds directly into the position aggregation layer, expressed in delta-equivalent metric tons, ready to be matched against futures or options hedges entered in the derivatives modules.
Linking Futures Hedges to Physical Positions in Ledger
Futures positions entered through the Derivatives Desk module carry their own field schema: TRADE_REF (broker-assigned or internal reference), EXCHANGE_CODE (LME, COMEX, MCX, SHFE), PROMPT_DATE (exchange-resolved), LOT_SIZE (standardized by exchange, 25MT per lot for LME copper), NET_POSITION (long or short in lots), OPEN_LOTS (unmatched against any physical position), HEDGE_DESIGNATION (trading or hedging for accounting classification), and OFFSET_CONTRACT_ID (the physical CONTRACT_ID this futures position is assigned against).
The OFFSET_CONTRACT_ID field is the operational mechanism that links a futures position to its physical counterpart. It is not an optional field. When a trader enters a futures sell to hedge a physical long, the OFFSET_CONTRACT_ID references the CONTRACT_ID of the physical position being hedged. The reconciliation engine uses this reference to calculate net exposure correctly. Without it, the futures position appears as a speculative short rather than a hedge offset, and the single book view overstates risk on both sides.
How Does a CTRM System Link Futures Hedges to Physical Delivery Obligations?
A CTRM system links futures hedges to physical delivery obligations through a shared reference key (in Novaex Ledger, the OFFSET_CONTRACT_ID field) that explicitly maps each derivatives position to the physical contract it offsets. The system then resolves both records to the same DELIVERY_PERIOD, allowing net exposure to be calculated in common units (delta-equivalent metric tons) across the combined physical-derivatives book. This design choice must be enforced at data entry; storing the two position types in adjacent modules does not automatically link them.
futures hedge designation accounting requirements metals CTRM
According to a 2023 Oliver Wyman study on commodity risk management, firms that enforce systematic hedge designation at trade entry reduce end-of-day position breaks by 73% compared to firms that reconcile hedge assignments post-trade. The OFFSET_CONTRACT_ID mechanism is how Ledger enforces that discipline structurally rather than leaving it to be maintained manually.
Once OFFSET_CONTRACT_ID is populated, the position aggregation layer reads the physical QUANTITY_MT, subtracts the futures NET_POSITION (converted from lots to MT using LOT_SIZE), and calculates the residual open exposure. This residual, the unhedged physical quantity, is displayed in the single book view as OPEN_MT alongside HEDGED_MT and TOTAL_CONTRACT_MT for each DELIVERY_PERIOD bucket.
Options Position Integration: Delta, Premium, and Expiry in One View
Options positions introduce a calculation layer that purely physical or futures books do not require: Greeks. A vanilla call or put, an Asian average-price option (standard in base metals for quotational period hedging), or a barrier option each carries a DELTA that changes daily with spot price, implied volatility, and time to expiry. Representing options in the same book as physical and futures positions requires normalizing them to a common unit: delta-equivalent metric tons.
The Derivatives Desk module captures options with the following fields: OPTION_TYPE (call, put, Asian AP, knock-in, knock-out), UNDERLYING_PROMPT (the LME or COMEX prompt the option references), STRIKE_PRICE, EXPIRY_DATE, NOTIONAL_QUANTITY (in MT), PREMIUM_PAID, DELTA (calculated against live mark-to-market price curves), DELTA_EQUIV_MT (DELTA × NOTIONAL_QUANTITY), and OFFSET_CONTRACT_ID (when the option hedges a specific physical position).
How Are Options Delta Equivalents Calculated in a Commodity Trading Book?
Options delta equivalents in a commodity trading book are calculated by multiplying the option's DELTA (a value between 0 and 1 for calls, -1 and 0 for puts) by the NOTIONAL_QUANTITY in metric tons. For a 500MT copper call option with a DELTA of 0.45, the DELTA_EQUIV_MT is 225MT long. This value changes as spot price, implied volatility, and time-to-expiry change, requiring recalculation against current mark-to-market curves on each price update rather than on a fixed daily batch schedule.
Asian average-price options used in metals QP hedging require a modified delta calculation that accounts for the averaging period already elapsed. The options pricing module in Novaex Ledger applies an elapsed-averaging adjustment factor to the standard Black-76 delta calculation. As a result, the DELTA_EQUIV_MT for a 10-day Asian option reflects the remaining fixing days alongside the instantaneous Black-76 delta.
Asian option delta calculation base metals QP hedging
According to LME 2023 market statistics, options open interest on LME base metals contracts increased 22% year-over-year, reflecting growing adoption of options as QP hedging instruments alongside standard futures. As options usage grows, the inability to represent options delta in the same book as physical and futures exposure becomes an increasingly material gap in position visibility. This gap returns the delta calculation to spreadsheets and manual processes.
The DELTA_EQUIV_MT field in Ledger is recalculated each time the pricing module receives updated price curves from LME, COMEX, MCX, or SHFE feeds. When LME copper prices move intraday, DELTA changes for all open options positions, DELTA_EQUIV_MT is recalculated, and the single book view reflects the updated net delta exposure without a manual refresh step from the trader.
The Reconciliation Mechanism: Field-Level Mapping Across Position Types
The single book view in Novaex Ledger acts as the output of a position reconciliation engine. It reads from a unified position schema enforced across the Physical Book module, the Derivatives Desk module, and the Options module.
The reconciliation engine operates on four shared fields present across all three position types:
DELIVERY_PERIOD: All positions resolve to the same exchange-defined period code. Physical contracts mapPRICING_DATEwindows toDELIVERY_PERIOD. Futures positions mapPROMPT_DATEtoDELIVERY_PERIOD. Options mapEXPIRY_DATEandUNDERLYING_PROMPTtoDELIVERY_PERIOD. The resolution logic for each exchange (LME third-Wednesday structure, COMEX first-notice-day rules, MCX and SHFE expiry calendars) is maintained in a reference table updated with each exchange calendar release.
COMMODITY_CODE: A standardized instrument identifier (e.g.,CU-LME-Afor LME Grade A copper,AL-LME-Pfor LME primary aluminum) that normalizes metal grade and exchange references across all position types.
QUANTITY_UNIT: All positions are expressed in metric tons. Futures positions are converted from lots to MT usingLOT_SIZEat entry. Options positions carryDELTA_EQUIV_MTas the book-facing quantity. Physical contracts carryQUANTITY_MTdirectly.
OFFSET_CONTRACT_ID: The linking key that associates derivatives positions with their physical counterparts, enabling net exposure calculation rather than gross aggregation of separate long and short books.
How Do Traders Verify That Physical and Derivatives Positions Are Fully Reconciled?
Traders verify full reconciliation in Novaex Ledger through the Position Integrity panel in the Risk Dashboard module, which flags any position where DELIVERY_PERIOD, COMMODITY_CODE, or OFFSET_CONTRACT_ID creates an inconsistency in the net exposure calculation. Flagged positions carry a RECONCILIATION_STATUS of UNMATCHED or PERIOD_MISMATCH rather than being silently included in aggregated totals. This ensures traders see the specific field reference causing the inconsistency instead of an unexplained variance in NET_DELTA_MT.
position reconciliation workflow CTRM metals risk management
According to a 2022 McKinsey Global Energy and Materials report, front-office traders in commodity firms spend 23% of their workday on data reconciliation tasks that should be handled at the system level. The RECONCILIATION_STATUS flagging mechanism in Ledger surfaces those failures at the position level, in the Risk Dashboard, before they propagate into end-of-day reports.
When all four shared fields are populated and consistent across position types, the reconciliation engine produces OPEN_MT, HEDGED_MT, NET_DELTA_MT, and UNHEDGED_PREMIUM_EXPOSURE for each DELIVERY_PERIOD bucket. These output fields displayed in the single book view are calculated directly from the data model rather than assembled from separate exports.
What Metals Position Reconciliation Looks Like in Practice
A concrete copper hedging scenario shows how all three position types enter and reconcile in the single book.
A trading firm purchases 1,000MT of LME Grade A copper for delivery against the LME March third-Wednesday prompt (DELIVERY_PERIOD: LME-MAR-3W), priced against the LME 3M average over a 10-day quotational period (PRICING_DATE: Feb 10 to Feb 21). The physical contract is committed to the Physical Book module: CONTRACT_ID: PHY-2024-0847, QUANTITY_MT: 1000, PRICE_BASIS: LME-3M, COMMODITY_CODE: CU-LME-A, DELIVERY_PERIOD: LME-MAR-3W. Open pricing exposure at entry: 1,000MT.
The trader sells 40 LME futures lots (40 × 25MT = 1,000MT short) to hedge the full QP exposure. The futures position enters the Derivatives Desk module: TRADE_REF: LME-F-2024-3821, EXCHANGE_CODE: LME, PROMPT_DATE: LME-MAR-3W, NET_POSITION: -40 lots (1,000MT short), OFFSET_CONTRACT_ID: PHY-2024-0847.
The reconciliation engine maps both records to DELIVERY_PERIOD: LME-MAR-3W and COMMODITY_CODE: CU-LME-A. Net calculation: 1,000MT long physical + 1,000MT short futures = NET_DELTA_MT: 0. The single book view shows HEDGED_MT: 1,000, OPEN_MT: 0, NET_DELTA_MT: 0.
The trader then buys a copper call option (500MT notional, $9,200/MT strike, EXPIRY_DATE: Feb 15, UNDERLYING_PROMPT: LME-MAR-3W) to participate in upside during the QP. At entry, DELTA: 0.38, DELTA_EQUIV_MT: 190MT long, OFFSET_CONTRACT_ID: PHY-2024-0847. The reconciliation engine adds this delta to the existing net position.
The single book now shows NET_DELTA_MT: +190MT, reflecting the delta exposure introduced by the option overlay, calculated from DELTA_EQUIV_MT at the current price curve, updated with each pricing module refresh. No spreadsheet, no manual delta lookup, no export-and-aggregate step.
copper QP hedging strategy with options overlay LME
According to a 2023 Bloomberg Commodities survey, 87% of commodity trading desks using options for QP hedging report that delta position tracking is their most manually intensive reconciliation task. The DELTA_EQUIV_MT field architecture in Ledger is the specific mechanism that removes that manual step from the workflow.
This is the operational value of the single book: three position components across two modules and three data schemas produce one number, NET_DELTA_MT: +190, updated with each price curve refresh, with the specific field path from raw position data to reconciled output fully traceable.
Access Technical Documentation and Request a Trial
The architecture described in this post (OFFSET_CONTRACT_ID linking, DELIVERY_PERIOD resolution logic, DELTA_EQUIV_MT recalculation methodology, RECONCILIATION_STATUS flagging in the Risk Dashboard, and the four-field shared schema across Physical Book, Derivatives Desk, and Options modules) is documented in full in the Novaex Ledger integration specification.
The technical documentation covers:
- Complete field schemas for the Physical Book, Derivatives Desk, and Options modules with data type, constraint, and required-field specifications
DELIVERY_PERIODresolution logic for LME third-Wednesday structure, COMEX first-notice-day rules, and MCX and SHFE expiry calendars- Asian option delta calculation methodology including the elapsed-averaging adjustment factor and its interaction with
DELTA_EQUIV_MTin the position book OFFSET_CONTRACT_IDassignment workflow covering both manual assignment and rule-based auto-assignment for high-volume hedging programs- Risk Dashboard module layout including
RECONCILIATION_STATUSflag definitions,PERIOD_MISMATCHresolution workflow, and Position Integrity panel configuration - Margin Monitor module integration with the Derivatives Desk for
MARGIN_REQtracking against open futures positions by exchange
For trading teams evaluating whether Ledger's single book architecture fits their physical-plus-derivatives workflow, a structured product trial provides access to the full position entry and reconciliation environment against live LME, COMEX, MCX, and SHFE price curve feeds.
Novaex Ledger product trial request
Position fragmentation in CTRM architecture directly results from platforms built without a shared data model across position types. The field-level mechanism that resolves it is documentable, testable, and specific. The documentation is available now.