Commodity Options Explained: OTC and Exchange Types, Modelling, Valuation and Risk

Executive summary

An option book is where an ETRM platform is most easily found out. A forward is a number and a date; an option is a model, a volatility surface, a set of sensitivities that move as the market moves, an early exercise decision, a margin obligation if it is cleared, and a credit exposure if it is not. Get the data model wrong and every downstream number, valuation, Greeks, margin, credit, settlement, is wrong in a way that is hard to see and expensive to unwind.

This guide does three things. First, it lays out the option taxonomy a commodity desk actually trades, roughly fifty distinct types across vanilla, average-price, multi-asset, barrier, digital, physical and structured families, and marks which trade OTC, which trade on exchange, and which trade both. Second, it sets out how each family should be modelled, because the modelling choice is a data-model decision before it is a maths decision. Third, it walks the option through the platform: valuation, position, market risk, credit risk, settlement, and reporting, and shows what each stage needs from the trade record.

The thread running through all of it: an option is one governed record that every function reads. The premium the back office settles, the delta the trader hedges, the exposure the credit officer monitors, and the figure the regulator sees must all come from the same trade and the same surface, or the desk spends its day reconciling instead of trading.

Why options break weak systems

A forward has a price, a quantity, and a delivery period. An option has all of those plus a strike, an expiry, an exercise style, an underlying that is itself a forward, a volatility input, a settlement convention, and a premium with its own payment date. That is not incrementally harder; it is a different shape of problem.

Three specific failures recur. The bolted-on option. A platform designed for forwards adds options as a special trade type with a few extra fields, so the option cannot express an averaging window or a barrier and the desk books it as a comment on a swap. The disconnected surface. Volatility lives in a spreadsheet the model reads at valuation time, so nobody can reproduce last Tuesday’s Greeks. The premium that floats free. The premium is captured as a cashflow unlinked to the option, so settlement pays it and the P&L double-counts it.

Each failure has the same root: the option was modelled as a variation of something simpler instead of as its own governed object with its own required attributes. The taxonomy below is the argument for why that does not work, there is too much genuine variety to flatten.

The canonical option object

Before the taxonomy, the object. Every option type in this guide, from a plain European call to a twelve-month swing contract, is stored on the same hierarchy. That is the single most important design decision an ETRM makes about options, and it is the one almost no vendor explains.

The hierarchy has eight levels, and each exists because something downstream needs it:

Read down the "why it is separate" column and the architecture argument makes itself. Trade and trade version are separate because reproducibility demands it. Leg is separate from trade because strategies demand it. Option terms are separate from pricing terms because the contract and the model are different things: the strike is what you agreed, the model is how you value it, and conflating them means changing a model silently rewrites history.

Every downstream engine consumes the canonical trade object. Pricing reads option terms plus underlying plus pricing terms. The position engine reads legs and underlying. Market risk reads the same positions plus the surface. Credit reads risk terms plus the valuation. Settlement reads settlement terms plus lifecycle events. Reporting reads all of it. None of them holds a private copy, which is precisely why the delta a trader hedges, the exposure a credit officer monitors, and the cash the back office pays are the same trade, computed once.

Modelling strategies as linked legs

Desks do not trade single options; they trade structures. A straddle, a collar, a butterfly, a risk reversal, these arrive as one negotiated package with one net premium. The modelling question is whether a strategy is a new kind of instrument or a collection of ordinary ones.

Gravitas models strategies as collections of linked legs, not as a separate strategy instrument. The reasoning is straightforward: a straddle is a call and a put. If you invent a "straddle instrument", you must also invent a strangle instrument, a butterfly instrument, a condor instrument, a seagull, a three-way collar, and every structure a desk dreams up next quarter. Each new instrument needs its own pricing, its own risk, its own settlement. That is how platforms calcify.

The payoff of this design is that a structure the desk has never traded before is bookable today. A new strategy is a new combination of legs, not a development project. That is what "configuration-first" means in practice, and it is why the leg has to be a first-class object rather than a field on a trade.

The multi-leg data model in practice

Once legs are first-class, the multi-leg questions answer themselves, but they are worth making explicit because they are where multi-leg platforms usually leak.

That last row is the one that breaks weak systems. In a butterfly, the short legs may be assigned while the long legs remain. If the strategy is one indivisible instrument, that event has nowhere to live. If it is legs, the event lands on the leg and everything downstream, position, risk, settlement, follows naturally.

The option taxonomy: vanilla and European-style families

Start with the instruments that make up the bulk of most books. These are well understood, which is exactly why a platform must handle them without ceremony.

The lesson from this first block is that "vanilla" already spans four exercise styles and two venues. A trade record that cannot express exercise style as a first-class attribute is already inadequate before the exotic families arrive.

Average-price and Asian families

Commodity markets settle against averages far more often than equity markets do, which makes the Asian family the workhorse of a physical desk rather than an exotic curiosity. A monthly-average price option on gasoil is a routine hedge, not a structured product.

The modelling point that matters operationally: an Asian option’s value depends on fixings that have already happened. Once the window starts, part of the payoff is known and part is stochastic. A platform that cannot store realised fixings against the trade cannot value a live Asian correctly, and the error grows as the window elapses.

Multi-asset and spread families

Commodity desks trade relationships as much as outrights, so the spread option is central rather than peripheral. Each of these is a multi-curve object, and its value depends on correlation as much as on either leg’s level or volatility.

Every option in this table depends on at least two curves. That is the operational headline: a spread option is only arbitrage-free if the curves underneath it were built to the same as-of instant on compatible conventions. The option model is downstream of the curve discipline described in our forward curve construction guide.

Barrier, digital and path-dependent families

These are the genuinely exotic families, and they are where a weak data model gives up entirely. Each carries attributes that simply do not exist on a vanilla, and those attributes are trade data, not model configuration.

Notice the pattern in the modelling column: barrier level, monitoring frequency, active window, fixing schedule, reset dates. These are all trade attributes. A platform that stores them in a comment field or a spreadsheet cannot value the trade tomorrow, cannot reproduce it at audit, and cannot risk it at all.

Physical, embedded and structured families

The final group is where commodity trading diverges most sharply from financial markets. These are options embedded in physical arrangements, and they are frequently the largest source of optionality on the book even though they are rarely called options.

Physical optionality deserves emphasis because it is so often invisible. A supply contract with a nomination range is a swing option whether or not anyone books it as one. Recognising and modelling that embedded optionality is the difference between a book you can risk-manage and a book with a large unmeasured short-volatility position hiding in the physical portfolio.

Master reference: every option type at a glance

The families above, consolidated. This is the quick-reference view: what trades where, how it settles, which exercise styles occur in practice, and which model values it. Venue and settlement columns record what is commonly seen rather than what is theoretically possible, since almost any OTC structure can be negotiated with either settlement method; "Rare" marks a form that exists but is uncommon.

A reference taxonomy covering 52 commonly traded structures, on one data model. That is the claim this article is making, and the sections that follow show what each engine does with them. This list is a working reference, not an industry standard, and it is not exhaustive.

How each family should be modelled

Modelling is a data-model decision before it is a maths decision. The pricing library is the easy part; the hard part is a trade record that carries every attribute the model needs and a surface that is governed and reproducible.

Rule one: attributes belong on the trade, not in the model. Barrier level, averaging window, weights, fixing schedule, heat rate, exercise dates, monitoring frequency, these describe the contract, so they live on the trade record. When they live in model configuration, two trades of the same type cannot differ, which is precisely what OTC means.

Rule two: the model is a versioned, configurable choice, not a hard-coded branch. The same option type may be valued with a closed form for speed intraday and Monte Carlo for the official close. That is a policy, declared and versioned, not a code path someone remembers.

Rule three: the volatility surface is governed data with lineage. A surface has an as-of instant, a source, an interpolation policy, and a version. Reproducing last month’s Greeks requires the surface exactly as it was, which means it is stored, not recomputed from whatever the spreadsheet holds today.

One further discipline: whatever the model, it must reprice the market. If the surface is calibrated to quoted vanillas, the model must return those quotes to solver precision, exactly the repricing check a curve engine applies. A model that cannot reproduce the instruments it was calibrated to is not a model, it is an opinion.

Exercise events: the part nobody documents

Exercise is where an option stops being a valuation exercise and becomes an operational one. It is also the least documented area in vendor literature, which is odd, because it is where the money moves.

Partial exercise is the acid test. A holder exercises 40% of a swing right, or half a block of listed options is assigned. If the platform models the option as an indivisible unit, that event has nowhere to go and the desk resorts to booking an offsetting trade, which corrupts the audit trail. On a leg-based model with quantity as an attribute, partial exercise splits the leg: part settles, part stays live, both trace to the original trade.

Assignment deserves equal care because it is inbound. The seller does not choose it, so the platform must accept an event initiated elsewhere (by the counterparty or the clearing house), apply it to the right leg, and cascade the consequences into position, risk, and settlement without manual intervention.

The option event lifecycle

Every option moves through a governed state machine, and every transition is an event with a timestamp, an actor, and a version. The states are not decoration; each one gates what may happen next.

Two transitions carry most of the operational risk. Approved to confirmed is where credit is consumed and the trade becomes binding, so the check has to happen before, not after. Active to partially exercised is the state most systems lack entirely, forcing a desk to either cancel-and-rebook (destroying history) or track the remainder in a spreadsheet.

Amendments, cancellations, novations, and assignments are all events against this machine, never in-place edits. An amendment creates a new trade version; a novation changes the counterparty and the netting set from a point in time forward; a cancellation closes the trade with a reason, leaving the record intact. History is append-only, which is what lets any past state be reproduced exactly.

The position engine: what an option contributes

This is where ETRM platforms differ most, and where an option book is either understood or merely listed. An option’s position is not one number; it is several, and they answer different questions.

The point of the table is that these are business views of one canonical position model, not separate calculations. An option contributes to the physical view only if exercised into delivery, contributes delta to the risk views continuously, and contributes to the trader and book views by attribution. If a platform computes these independently they will disagree, and reconciling them becomes a daily job.

Two option-specific position problems deserve naming. Expiry bucketing: options must be bucketed by expiry as well as by delivery tenor, because a large near-expiry short-gamma position is a different animal from the same delta spread across a year. Exercise risk: the position that would exist if options exercised is not the position that exists today, and a desk needs both views, particularly approaching expiry.

The valuation pipeline

Valuation is a pipeline, not a function call. Each stage has an owner, a governed input, and a reproducible output, and an option consumes the whole chain rather than just the last box.

The chain matters because of where errors enter. A wrong quote poisons the curve; a bad curve poisons the option value; a stale surface poisons the Greeks; and every one of those errors is invisible in the final number. That is why each stage is gated and versioned rather than merely computed, the same discipline described in our forward curve construction guide, applied one layer up.

The Greeks point is worth isolating. Greeks must come from the same valuation run as the MTM. When a platform computes MTM in one engine and Greeks in another, the two drift, and the trader hedges against a delta that does not correspond to the value the book is carrying.

The volatility surface as a governed data object

Every model in the table above needs one input a forward book never asks for: a view of how volatile the market expects the underlying to be. That view is not a number. It is a surface, and it deserves the same treatment as the trade record itself.

Treating the surface as a first-class governed object, rather than as configuration inside the pricing engine, is what makes an option valuation reproducible. The trade record says what was agreed; the surface version says what the market looked like when it was valued; the model policy says how the two were combined. Lose any one of the three and last quarter’s number cannot be defended.

The practical failure is mundane: a surface is rebuilt intraday, nobody records which build priced the four o’clock snapshot, and the P&L explain the next morning has a gap nobody can close. The fix is equally mundane, and it is the same discipline the forward curve layer already demands: version it, store the inputs, and make the build reproducible on request.

Valuation in Gravitas

An option in Gravitas is one governed record on the same data model as the rest of the book. Valuation reads that record and the governed surface, applies the configured model for the instrument, and produces a value that every other function sees immediately, because there is no second copy to synchronise.

Concretely, valuation needs four things from the platform, and each is a governed object rather than an input someone supplies: the trade record with every contractual attribute; the forward curve for the underlying, built and validated as described in our curve guide; the volatility surface, versioned and as-of; and the discount curve for present-valuing the payoff and the premium.

Because the option and the forward it references share the same governed curve, an option and its delta hedge value against the same numbers. That sounds trivial and is not: in a many-model system the option desk and the forward desk can value against different copies of the same curve, and the residual shows up as unexplained P&L that nobody can attribute.

Reproducibility is the property that matters at audit. Every option valuation traces to the trade version, the curve version, the surface version, and the model version that produced it, so a valuation from any past date can be reconstructed exactly rather than approximated.

Position and market risk

An option’s position is not its notional. A 100,000 barrel call is not a 100,000 barrel long; it is a delta-equivalent position that changes as the market moves, and that distinction has to be native to the position model rather than a report-time adjustment.

Risk computes the Greeks per option and aggregates them across the book: delta (and delta-equivalent position), gamma, vega, theta, and rho, plus the cross-Greeks that matter for spread options. Because the risk engine reads the same governed positions as the valuation engine, the delta a trader hedges is computed on the same trade the back office will settle.

Two option-specific risk points deserve care. Non-linearity defeats linear VaR. A delta-only VaR on an option book understates the tail, because the whole point of an option is that the payoff bends. Full revaluation under scenarios, as the risk module supports, is the honest measure. Vega is a surface, not a scalar. Reporting one vega number hides the strike and tenor structure where the actual risk lives.

Scenario and stress testing matter more for options than for forwards, precisely because the relationship between market move and P&L is not a straight line. A shock that is unremarkable for a forward book can be severe for a short-gamma option book, which is why scenarios shock volatility and correlation, not only price.

Credit risk on the option book

Credit is where OTC and exchange options diverge most sharply, and the platform has to model both without pretending they are the same.

Exchange-traded and cleared options face a clearing house. Bilateral counterparty exposure to a specific dealer is largely replaced by exposure to the CCP, backed by daily variation margin and initial margin. Default risk is reduced, not eliminated: residual exposure remains to the CCP itself, to the clearing broker, and to the default-fund arrangements that mutualise losses. The platform’s job is to track margin calls, reconcile them to the broker or CCP statement, and post them correctly, so the day-to-day question shifts substantially toward liquidity, can we fund the margin, without the default question disappearing.

OTC options face the counterparty directly, and the exposure profile is asymmetric. A purchased option is an asset: the buyer paid the premium and now carries exposure to the seller for the whole life, and that exposure grows as the option moves into the money. A sold option is a liability: once the premium has settled, the seller typically retains minimal residual counterparty exposure on the option itself, and carries the obligation to perform. Residual exposure can still arise, for example from unsettled or deferred premium, from collateral posted under a CSA, or where the option sits inside a wider netting set with the same counterparty.

Potential future exposure is where option credit gets interesting. Current exposure is just the mark-to-market, but a purchased option’s exposure can grow substantially if the market moves, so a credit framework that only looks at today’s MtM understates the limit consumption. This is why option credit is modelled as a distribution over the life, not a single number today.

In Gravitas, credit and limits are checked at capture, so an option that would breach a counterparty limit is blocked or flagged before it is booked, and exposure is monitored continuously thereafter against the same governed positions the risk engine uses.

The mechanics that make OTC option credit work, each of which is trade or agreement data rather than a calculation setting:

Wrong-way risk is worth dwelling on because commodity books create it naturally. A gas producer that sells you calls on gas is most likely to default when gas prices spike, which is exactly when your option against them is worth most. A credit framework that treats exposure and default probability as independent understates that materially.

Settlement across the option lifecycle

Options have more lifecycle events than forwards, and each is a settlement obligation. Settlements handles them from the same trade record, so the amounts settled reconcile to the amounts valued by construction.

The event to watch is physical exercise. An option that exercises into a physical position must create that position and hand it to scheduling for nomination and delivery, and then to settlement for invoicing on the delivered volume. On a single-model platform that hand-off is automatic because it is the same record moving through the lifecycle. On a many-model platform it is an integration, which means it is a reconciliation, which means it is a place breaks happen.

Premium deserves its own note. It is a cashflow attached to the option, so it settles once, reconciles to the trade, and cannot be double-counted in P&L. The common failure, booking premium as a standalone cash entry, is exactly what breaks the tie-out between the settled cash and the valued position.

The full settlement chain runs from the option to the ledger, and each hand-off is a place a weak platform leaks:

Reporting the option book

Reporting draws from the same governed data, which is what lets the option book tie out across every view. Positions, P&L, risk, and regulatory reports agree because they read one record, not four copies.

Position reporting must show both the notional and the delta-equivalent position, because they answer different questions. A report that shows only notional overstates the directional risk of a far out-of-the-money book; one that shows only delta hides the gross obligation.

P&L attribution is where an option book is most demanding. The daily change decomposes into delta P&L (market move), gamma P&L (the second-order effect), vega P&L (surface move), theta (decay), and new trades. If those components do not sum to the actual change, something is unexplained, and unexplained P&L on an option book is the earliest signal that a model, a surface, or a trade record is wrong.

Regulatory reporting treats OTC and exchange options differently. OTC derivatives carry trade-reporting obligations under regimes such as EMIR and REMIT, with the option’s economic terms reported; cleared trades report through the clearing chain. The platform must classify each option correctly and produce the required fields from the trade record, traceably.

And because the model is bitemporal, an option report as of any past date reproduces exactly, on the trade, curve, and surface versions live at that moment, which is what an auditor asks for and what a reconstructed spreadsheet cannot honestly provide.

The report inventory an option desk actually runs, all from the same governed data:

What a good option data model looks like

Pulling the thread together, the option record has to carry everything the downstream stages need, because every stage reads the same record.

Read that table as a specification. If an ETRM platform cannot store a barrier’s monitoring frequency or an Asian’s realised fixings as governed trade data, it cannot value those options tomorrow, cannot risk them today, and cannot reproduce them at audit. The taxonomy earlier in this article is, in effect, the list of attributes a serious option model has to accommodate.

The end-to-end architecture

Every engine described in this article is a stage in one pipeline, and every stage reads the same canonical option object rather than a private copy.

The architectural claim is narrow and testable: no stage holds its own copy of the option. The delta the risk engine reports and the delta the trader hedges are the same number because they are the same object read twice, not two calculations that should agree. Extend that across thirteen stages and you have the difference between a platform and a collection of systems.

Why most ETRMs struggle with exotic options

The failure modes are consistent across platforms, and they are architectural rather than mathematical. Nobody struggles with Black-76; they struggle with everything around it.

Notice that every row traces back to the same root: the option was not modelled as a governed object with its own attributes. Everything else, the spreadsheets, the reconciliations, the disagreeing deltas, is a symptom.

The Gravitas answer is architectural rather than a longer feature list:

That is a claim about structure, not about being better at maths. The pricing library matters far less than whether the platform can hold the trade, reproduce it, and let every function read the same one.

Conclusion

Options are the instruments that separate an ETRM platform that manages a book from one that merely records trades. The taxonomy is genuinely wide, roughly fifty types across vanilla, Asian, spread, barrier, digital, physical and structured families, spanning OTC and exchange, and each family brings attributes that a forward-shaped data model cannot express.

The platform requirement follows directly. Store every contractual attribute on a governed trade record. Treat the volatility surface as versioned, reproducible data with lineage. Make the model a declared, versioned policy rather than a hidden branch. Then let valuation, position, market risk, credit, settlement, and reporting all read that one record, so the delta the trader hedges, the exposure the credit officer monitors, the cash the back office settles, and the figure the regulator reads are the same trade, computed once.

That is the whole argument for a single governed model, and an option book is where it either holds or visibly fails. If you want to see how the curve layer beneath all of this is built and validated, our guide to forward curve construction covers the foundation every option model stands on.