Market-data layer
The volatility surface starts with a reliable option book.
The first visible Derivasys product is a volatility surface, but the first engineering dependency is a usable option order book. Every implied-volatility point depends on a current bid, ask, mark, strike, expiry, instrument convention, and expiry-matched forward.
When a book is wrong, everything downstream can look wrong in a sophisticated way. The SVI fit can still converge. The dashboard can still render a smooth curve. The problem is that the curve may be fitting stale, crossed, or mismatched market state.
- Normalize instrument names, strikes, expiries, option type, and contract multipliers.
- Apply snapshots before deltas and reject out-of-sequence updates.
- Track bid, ask, mark, trade, open interest, and venue timestamp independently.
- Expose enough provenance for the volatility layer to reject weak quotes.
Instrument normalization
The book key has to normalize venue symbols into one internal contract.
A crypto options book starts to break long before pricing if instrument identity is inconsistent. Venue symbols encode currency, expiry, strike, option type, settlement convention, and sometimes instrument family in different shapes. The volatility layer should not parse those strings again.
Derivasys treats instrument normalization as a first-class boundary. Once a venue message becomes an internal option key, every downstream worker can join quotes, trades, futures, forwards, SVI fits, risk reversals, and flies without knowing the venue-specific symbol grammar.
- Normalize currency, expiry timestamp, strike, option type, venue, and contract multiplier.
- Reject messages whose instrument key cannot be mapped deterministically.
- Store the raw venue symbol beside the normalized key for audit and replay.
- Version contract metadata so historical replay uses the convention that was live at the time.
VenueSymbol -> parse currency / expiry / strike / option_type -> attach venue and contract metadata -> OptionInstrumentKey -> book_state[OptionInstrumentKey]
Snapshot and delta
Snapshots and incremental updates need explicit sequencing.
Exchange feeds usually arrive as a full snapshot followed by incremental updates. The book builder has to know whether it has a complete snapshot, whether every delta belongs to that snapshot, and when a gap requires a resubscribe.
A common failure mode is subtle: the feed is connected, messages continue arriving, and the UI is live, but one instrument's book is missing an update. The volatility surface then inherits a quote that looks current but is internally inconsistent.
snapshot -> initialize book state update -> verify sequence update -> apply bid and ask deltas quote -> publish best bid, best ask, mark, source timestamp vol -> consume only quote states that pass freshness and crossing checks
Sequence recovery
Sequence gaps should quarantine the affected instrument before they poison the surface.
The dangerous failure mode is not always a disconnected WebSocket. It is a connected feed with one missed delta. The book still has a bid and ask, the dashboard still looks live, and the SVI fit can still produce a smooth smile from a quote that is no longer internally reliable.
A sequence gap should therefore quarantine the specific instrument or expiry until a fresh snapshot restores confidence. That is better than letting a questionable wing quote trigger IV inversion, distort a fit, and move a risk node.
- Track last sequence by venue and instrument, not only by connection.
- Mark affected quotes as sequence_stale until a replacement snapshot is applied.
- Publish gap and resubscribe events into monitoring instead of hiding them in logs.
- Keep unaffected instruments live so one gap does not blank the whole surface.
if update.sequence != last_sequence + 1: mark_instrument(sequence_stale) request_snapshot(instrument) publish_gap_event(instrument, last_sequence, update.sequence)
WebSocket ingestion
Exchange connectors should normalize WebSocket messages before the book layer.
A crypto options connector should not let Deribit, OKX, or any other venue convention leak directly into SVI calibration. Its job is to turn venue-specific WebSocket snapshots, deltas, trades, futures, and heartbeats into a small internal event contract.
That boundary matters because transport health and market-data health are different things. A WebSocket can stay connected while one instrument is stale, one expiry is missing deltas, or one venue sequence has fallen behind the rest of the surface.
- Keep raw venue payloads available for replay and debugging.
- Normalize instrument names, option type, strike, expiry, currency, venue timestamp, and sequence information.
- Emit explicit resubscribe, heartbeat, and gap events instead of hiding them inside logs.
- Separate exchange connectivity failures from quote-quality failures consumed by the volatility layer.
- Publish compact quote-state events so downstream workers do not need to understand exchange-specific WebSocket formats.
venue_message -> decode_exchange_payload -> validate_sequence_or_gap -> normalize_instrument_key -> update_book_state -> publish_quote_state -> record_raw_payload_for_replay
Quote quality
Not every top-of-book quote should become an IV point.
The volatility layer needs more than a best bid and best ask. It needs to know whether the quote is fresh, two-sided, crossed, wide, trade-supported, or close enough to the fitted smile to be trusted.
Derivasys treats quote quality as part of the data contract between the order-book worker and the volatility worker. That keeps the SVI calibration from compensating for a bad venue point when the real issue is market-data quality.
- Reject crossed or negative-spread books before IV inversion.
- Flag stale instruments separately from missing instruments.
- Keep bid, ask, mark, and last trade provenance visible.
- Avoid letting one far-wing update dominate the fitted smile.
- Publish quote-through-fit status beside the curve, not only after calibration.
Mark selection
The IV input should explain whether it came from bid, ask, mark, mid, or trade.
A best bid and ask are not enough to explain the volatility point. Liquid ATM options can often use a tight mid or venue mark. Far-wing options may need trade support, wider tolerance, or rejection when the displayed quote is too stale or too wide.
The order-book layer should publish enough provenance for the volatility worker to choose a pricing input deliberately. That keeps implied volatility, SVI residuals, and through-fit panels explainable when a single quote moves a wing.
- Publish bid, ask, mark, last trade, spread, trade age, and venue timestamp together.
- Flag whether the chosen IV input came from mid, venue mark, trade, or fallback.
- Use wider caution on deep wings, short expiries, and low-vega options.
- Store quote-width and source labels so residual diagnostics can explain outliers.
QuoteInput {
bid,
ask,
mark,
last_trade,
chosen_price,
chosen_price_source,
spread_bps,
quality_flags
}Forward link
The book cannot be separated from the expiry forward.
Options are not compared by strike alone. Each quote has to be interpreted relative to the expiry forward so the volatility layer can compute log-moneyness, delta buckets, risk reversals, flies, and SVI total variance.
A clean option book with a stale forward can still produce misleading risk nodes. This is why the book state, futures state, and volatility state have to be versioned close together.
- Attach the forward source and timestamp used for each expiry.
- Recalculate moneyness when the forward moves enough to matter.
- Keep fixed-strike and fixed-delta views separate in scenario reports.
- Record whether a risk node came from live quotes, interpolation, or extrapolation.
Forward versioning
Book state and forward state need a shared version for reproducible moneyness.
Option quotes become comparable only after they are placed relative to the expiry forward. If the book update and forward update are mixed from different moments, log-moneyness, delta buckets, risk reversals, flies, and SVI total variance can all shift for reasons that look like market movement but are really state mismatch.
The fix is to version the book and forward context together before publishing quote-state events. The volatility layer can then reproduce the exact forward used for IV inversion and later explain why a strike moved from one delta bucket to another.
- Attach forward value, forward source, and forward timestamp to every quote-state event.
- Record whether the forward came from futures, index, interpolation, or fallback.
- Rebuild moneyness only from a coherent book-forward version pair.
- Publish forward-change events when the move is large enough to remap visible delta nodes.
Event contract
The useful output is a compact quote-state event.
A downstream volatility worker should not need to understand every exchange-specific update shape. It should consume normalized quote-state events with enough metadata to decide whether an option can become an implied-volatility point.
That event boundary also makes replay easier. If the SVI weighting logic changes, historical quote-state events can be replayed without reimplementing every exchange websocket.
QuoteState {
venue,
instrument,
expiry,
option_type,
strike,
best_bid,
best_ask,
mark,
last_trade,
forward,
source_timestamp,
local_received_at,
sequence,
quality_flags
}Deterministic replay
A book incident should be replayable without reconnecting to the exchange.
When a surface incident is traced to market data, the useful debugging artifact is a deterministic replay of the book state that produced it. Replaying raw payloads into the same normalization and sequencing code makes it possible to test fixes without waiting for the market to repeat the event.
Replay also keeps later Kafka work honest. If quote-state events are compact but lossy, the team cannot reconstruct why an IV point, SVI fit, or dashboard patch moved. The order-book contract should preserve enough provenance to make old surface states explainable.
- Store raw venue payload, normalized key, sequence, receive timestamp, and applied action.
- Replay snapshots and deltas through the same validation code used in production.
- Compare rebuilt QuoteState output with the original published event.
- Use replay to test changes to sequence handling, quote filtering, and mark selection.
raw_payload_log -> replay_normalizer -> replay_book_builder -> rebuilt_quote_state -> compare original QuoteState
Downstream gates
Volatility and SVI workers should consume quality flags, not rediscover book errors.
If every downstream worker has to infer quote quality from scratch, the system becomes inconsistent. The order-book layer should publish clear quality flags and provenance so IV inversion, SVI calibration, risk-node extraction, dashboard diagnostics, and API consumers all agree on which inputs are trusted.
That does not mean the book layer makes model decisions. It means it gives the model layer enough evidence to reject bad inputs, weight weak points cautiously, and show users why a quote was accepted or ignored.
- Pass freshness, crossing, width, sequence, source, and interpolation flags downstream.
- Let SVI weighting use quote-quality metadata instead of only residual size.
- Keep rejected quote counts visible beside accepted fit diagnostics.
- Ensure risk reversals and flies can trace back to the quote-state events behind each wing.
Dashboard impact
Order-book errors should be visible before they become surface errors.
The dashboard should make the data pipeline inspectable. Quote-through-fit panels, update timing, venue provenance, and fixed-tenor rows give the user a way to see whether the surface is being driven by real market structure or by a bad book state.
That is the reason Derivasys treats the book layer as part of the volatility product. The final surface is the visible artifact, but book construction determines whether that artifact is trustworthy.
Links