Broker Market Data: Who Owns the Price, the Signal and the Licence?

An options-data purchase can involve five different businesses: an exchange feed, a general market-information desktop, a cleaned historical research database, a live derivatives analytics service and infrastructure for storing or replaying tick data. Comparing them as substitutes obscures what the buyer actually needs and inflates the apparent amount of duplicated spending.

The historical report combined vendor comparisons with an institutional operating perspective. This synthesis removes company and product names while retaining the architectural distinctions. It is a reference framework with no investment call. The procurement conclusion is straightforward: establish the decision, the timing requirement and the required rights before ranking suppliers.

One option produces several kinds of data

Observed option data and successive transformations

These layers should not be treated as equally direct measurements. If two suppliers report different implied volatilities for the same contract, one may use a different price selection rule, dividend assumption, interest-rate curve, exercise treatment or timestamp. The difference is not automatically a data error.

Before purchasing, define the required object. A trader managing intraday exposure may need timely quotes and sensitivities. A researcher testing an option-return strategy may need survivorship-aware history, corporate-action treatment and reproducibility. A control team may need evidence of the observable inputs used to value a position at a particular time.

Options-data services solve different parts of the workflow

Historical cleanliness is an economic asset

Research datasets earn their place by doing difficult work consistently. Options expire, strike grids change, corporate actions modify contracts and liquidity concentrates in selected maturities. A dataset that is easy to query can save substantial research effort if those adjustments are documented and reproducible.

The most valuable history is not merely long. It preserves the contract universe that existed at the time, distinguishes quoted from traded observations and makes the treatment of stale or crossed markets visible. A backtest can look attractive because the dataset excludes inconvenient contracts or uses information revised after the decision date.

Look-ahead bias is especially easy to introduce through surfaces and end-of-day files. If a strategy claims to trade before the close, it cannot legitimately use a cleaned value assembled from later observations. Corporate-action files and underlying identifiers must also be available on the relevant historical basis.

The original assessment emphasised the network effect of widely used research history: researchers, existing models and published methods may already be calibrated to its conventions. That makes substitution expensive even when another source has similar nominal coverage. The buyer should nevertheless distinguish convenience and reproducibility from an unsupported claim that one dataset is universally authoritative.

End-of-day and intraday are different products

An end-of-day database can be well suited to cross-sectional research, long-horizon factor studies and model development. It does not automatically support intraday execution analysis. A product with a familiar name may sell intraday snapshots or specialised extensions under separate terms, but those are additional products with their own coverage and methodology.

Intraday analysis needs timestamps whose meaning is clear. Exchange event time, receipt time and storage time answer different questions. A latency study using receipt timestamps from different collection points can measure network placement rather than market behaviour. An execution-quality study needs the information set available at the decision time, including the relevant underlying-market state.

The historical source identified this as a structural boundary between research-focused and live-analytics suppliers. The implication is not that one category is inferior. It is that the same institution can rationally use different services for academic-style research, live risk and post-trade review.

Procurement should therefore require a field-level specification rather than a generic promise of “historical options data”. State the frequency, timestamp convention, historical depth, contract coverage, cleaning policy and availability of raw observations. Confirm whether the service includes delisted underlyings and expired contracts.

Model differences need to be reproducible

Consider an implied-volatility calculation. Let $P_m$ be the observed option price, $S$ the underlying price, $K$ the strike, $r$ the interest rate, $q$ the dividend yield and $T$ the time to expiry. Implied volatility $\sigma$ solves

$$P_{\mathrm{model}}(S,K,r,q,T,\sigma)=P_m.$$

The result depends on the model and all its inputs. Two providers can use identical option prices and still disagree because they treat exercise features or dividends differently. In illiquid contracts, the choice between a bid, offer, midpoint or last trade can dominate the result.

A sensible comparison therefore reconstructs selected outputs from raw inputs. Choose representative contracts across moneyness, maturity and liquidity. Include corporate actions and low-price options, where small absolute price differences can create large volatility differences. Ask each supplier to explain the calculation rather than simply ranking the outputs by proximity to a preferred number.

Store model version and assumptions with the derived dataset. Otherwise a vendor methodology update can create an apparent change in market conditions. Reproducibility matters not only for research credibility but also for model validation and production incident diagnosis.

Tick infrastructure solves a different bottleneck

A tick store provides capture, compression, time-series query, replay and retention. Its commercial value comes from processing large data volumes reliably. It may contain analytics, but it does not eliminate the requirement to license the relevant feeds.

The buying decision should begin with workload shape. Are queries mostly recent and intraday, or long-range historical scans? Is the dominant challenge ingestion throughput, compression, point-in-time joins or concurrent research access? A system that excels at one workload may be expensive for another.

Data correctness still has to be designed. Capture gaps, duplicated messages, late arrivals and sequence resets require explicit treatment. A fast query engine can return a wrong answer very quickly if the ingestion process silently loses events. Monitoring should compare expected and observed message counts and preserve the ability to replay from durable raw data where permitted.

The historical report also treated supplier consolidation as a potential source of commercial change. For a buyer, the useful response is to review ownership of stored data, export formats, migration assistance and the relationship between the software licence and third-party data rights. An acquisition does not itself establish either improved capability or inevitable price increases.

A layered proof of concept prevents category errors

Run separate tests for source quality, transformation quality and infrastructure performance. A combined demonstration can hide which component produced the benefit.

Test source quality, transformations and infrastructure separately

The historical materials did not provide one universal numerical acceptance threshold, and this report does not invent one. The threshold should follow the business requirement. A daily research job and a live execution service need different latency and recovery objectives.

The trial should contain difficult observations: stale underlying prices, wide markets, deep out-of-the-money contracts, shortened sessions, exchange interruptions and contract adjustments. A platform that handles only clean examples has not demonstrated the competence that makes options data valuable.

The licence is part of the architecture

Desktop access, research access, internal redistribution and externally distributed derived outputs can have different rights. A researcher exporting a dataset for a prototype does not establish that the same workflow can be deployed across an institution.

Clarify who can receive the data, where it can be stored, whether affiliates are included and which derived values may be retained after termination. Model training, automated decision systems and client-facing analytics may have separate contractual treatment. These questions should be resolved before a successful prototype creates dependence.

Total cost includes entitlements, infrastructure, data engineering, methodology support and the work required to preserve reproducibility. A broad desktop platform may be expensive per user while reducing the need for several narrower tools. A specialist dataset may be inexpensive relative to the research time it saves. The correct comparison is the cost of the completed workflow, not the price of a superficially similar screen.

A controlled comparison portfolio

A useful test portfolio should include short- and long-dated contracts, several moneyness bands, different exercise features and both liquid and illiquid observations. Add a contract affected by a corporate action and a session with unusual market conditions. The purpose is to reveal conventions that a normal-data demonstration can hide.

For each contract, retain the raw quote, underlying price, timestamp, dividend treatment, curve input and model convention. Compare the price first, then implied volatility and sensitivities. If the price differs, investigate the selected observation before debating the model. If prices agree but sensitivities differ, investigate calibration and numerical settings.

This sequence prevents a common procurement mistake: assuming the preferred supplier is correct and treating every difference as a defect in the challenger. The decision should follow explainable behaviour and suitability for the intended workflow. Some differences will remain because the products serve different purposes. Documenting those differences is a better outcome than forcing superficial numerical agreement.

Broker-derived observations broaden the options-data problem

The later market-data report extends the original options-data architecture into OTC broker observations. A traded price, executable quote, indicative quote and assessed value are different evidence. An analyst must know which object a field represents before using it for valuation, liquidity measurement or a model input. Product names can obscure this distinction because one package can contain several evidence types and transformations.

The source-to-product chain begins with market activity captured by a broker or venue. Identifiers, timestamps and conventions make the observations usable. Curation removes errors, normalises terms and constructs histories. Analytics may derive curves, surfaces, benchmarks or valuations. Distribution delivers the product through files, APIs or terminals under an entitlement. Each stage can add value, but also introduce assumptions that must remain visible.

An observed OTC quote is not an exchange closing price. It can reflect a particular size, credit relationship, currency convention or dealer interest. Sparse instruments require interpolation and stale-value policies. A clean historical file may already embody decisions about outliers, missing periods and revisions. Backtesting on that file without retaining its vintage can make a strategy appear to know more than was available in real time.

A current example: combine price with the cost of moving the asset

On 11 March 2026, Parameta Solutions and Marex announced a joint netback-pricing product combining oil benchmarks and freight intelligence. The primary announcement illustrates an economically meaningful product combination: a quoted oil price alone is insufficient to assess a route after transport cost. This is a vendor-announced offering, not independent evidence of forecasting accuracy or customer return.

The public edition does not repeat the source report’s historical provider revenue table as if it were an October run rate. Financial comparison requires the same reporting period, currency and segment perimeter, including intercompany revenue and adjusted versus statutory profit. A six-month observation cannot be annualised without a stated assumption, and total divisional revenue cannot be compared casually with a competitor’s external data sales. Those differences are often more important than the apparent precision of the number.

Licensing determines whether an AI workflow is deployable

The September report adds an important purchasing dimension: permission to display data is not necessarily permission to feed it into a model, create derived products, redistribute outputs or store the history indefinitely. Check each intended use explicitly against the actual contract. A technical connector can make data accessible while the rights to a proposed workflow remain unresolved.

Construct an entitlement matrix with dataset, legal entity, user or system, display/non-display use, permitted transformation, retention and redistribution. The matrix should follow derived outputs to their recipients. When a model explains a price using a licensed curve, the institution needs to know whether sharing the curve, model inputs or derived result is permitted. This is contract-specific and not a general legal conclusion about all AI use.

Replacement should test the missing observations

The most useful challenger test is not a broad correlation between two clean datasets. Divide the universe into liquid observations, difficult tails and economically important gaps. Compare bid/ask convention, time of capture, update frequency, contributor diversity and revision policy. Investigate the discrepancies that change a trade, valuation reserve or risk decision. A replacement that agrees on obvious instruments but fails on the hard cases may be a poor substitute despite a lower fee.

The source’s institutional-spend and switching cases remain illustrative. A reproducible proof of concept should record what the incumbent supplied, what the challenger supplied, what the validator concluded and which rights each offered. The best commercial argument is the cost of obtaining equivalent decision evidence, including integration and the consequences of missing coverage. This naturally joins the original article’s separation of source, research history and trading engine: market intelligence is useful only when provenance and timing survive the full path to action.

Operating controls after purchase

Keep entitlement changes in the same change register as feed and methodology changes. A technically available dataset can become unusable for a planned workflow if its permitted distribution changes.

Assign owners for the raw data, transformations, research conventions and production interfaces. Publish a data dictionary and maintain a change log. When a vendor changes methodology, affected users should know whether historical values have been restated and whether models need revalidation.

Monitor missing contracts, unusual spreads, abrupt surface changes, stale observations and unexpected changes in implied-volatility distributions. Some alerts will reflect real markets; others will identify data failures. The escalation process needs people who understand both options and the data pipeline.

Maintain a reproducible sample portfolio for regression checks. It should include ordinary and difficult instruments, with expected behaviour under known input changes. This is more useful than checking that an application opens successfully after an upgrade.

The coherent options-data stack is consequently layered. Observable market inputs, cleaned history, live analytics and tick infrastructure each have a distinct role. Duplication is wasteful when two products provide the same unused capability. It is valuable when independent layers preserve research integrity, support different timing requirements or provide a controlled challenge to model outputs.

Primary sources checked for this edition

• TP ICAP / Parameta / Marex — Joint netback offering combines oil and freight data. Source date: 2026-03-11. https://tpicap.com/tpicap/media/press-releases/2026/parameta-solutions-and-marex-launch-joint-netback-pricing-offering-combining-oil-and-freight-data