One price, several permissions: the economics behind market-data revenue

CME reported data-revenue growth on October 21, 2026. That small piece of an exchange's accounts invites a larger question: what is being sold when the same price reaches a person, a risk engine and a customer application?

The observation need not change. Its role does. A price can help someone decide whether to trade, revalue an existing position without a trade, or become an input to a service sold elsewhere. This is why a data business deserves a separate reading from the activity on the trading venue. The following is Open Market Notes' economic analysis, using hypothetical workflows rather than estimates of any customer's bill.

A price travels farther than a trade

Imagine a manufacturer whose analyst watches a commodity quote. A background program uses the same observation to estimate the exposure on inventory. A customer portal then combines it with other inputs to present an indicative cost. There is one underlying observation and three different jobs. Whether those jobs need separate permissions or payments depends on the actual products and agreements; the example establishes no tariff.

The economic distinction is useful nevertheless. The analyst values an intelligible view. The risk program values reliable updates that arrive without a person intervening. The portal values an input it can incorporate into an external service. Their willingness to pay can differ even if the number carried through the systems is identical.

A supplier can therefore organize a commercial offer around use, rather than charge only for moving bytes. That does not establish ownership of every number anyone might observe. It identifies a narrower business proposition: a specified feed, with a particular timeliness, continuity and permitted destination. Buyers should evaluate that proposition, rather than assume either that a visible price is unrestricted or that every reuse necessarily creates another charge.

The difficult denominator is access

Nasdaq's US data policies distinguish human display from non-display use and specify counting units including devices and subscribers. The applicable treatment depends on the arrangement.

That distinction makes measurement part of the product. A connection count, a staff count and a software-process count describe different things. One gateway can distribute data to many destinations. Conversely, several technical connections can serve one tightly bounded task. Neither observation alone tells an analyst how many billable units exist.

For an internal operating model, an entitlement is best understood as a record of who or what is allowed to reach a dataset for a defined purpose. It is different from a log showing that access occurred. A dormant permission and a frequently used permission may look identical in one inventory and entirely different in another. Which record matters for billing must be established from the applicable terms, not guessed from a dashboard.

This suggests a practical design principle, not a universal contractual requirement: keep the identity, purpose and destination of a workflow visible alongside its technical traffic. A team that can explain how a price moves through its systems can discuss a licence change more precisely. A team that knows only its bandwidth risks negotiating around the wrong denominator.

Trading volume and the licence base run on different clocks

Trading volume measures a flow over a period. A hypothetical licensing business might instead earn revenue from a stock of subscribed users, permitted applications or broader arrangements. More trading can make the information more useful without increasing that stock immediately. More licensed workflows can expand the stock while executed volume is unchanged.

Consider a quiet trading month in the manufacturer's example. Its inventory still exists, so the exposure calculation may remain valuable. Now consider a frantic trading day handled by exactly the same systems. Message traffic can surge without any new user or application appearing. These examples explain why data revenue divided by contracts traded is not automatically a meaningful unit price.

For the same reason, revenue growth alone cannot identify adoption. A useful analytical bridge would separate the effects of the customer base, applicable rates, product mix and changes in measured scope. Without those disclosures, attributing growth to a wave of new machine users would be speculation. Describing it as pure pricing power would be equally premature.

Nor does a permission-based business automatically become immune to cycles. Customers can consolidate tools, renegotiate arrangements or stop using a workflow. An annual commitment may delay an adjustment rather than eliminate it. The relevant question is how deeply the data is embedded in continuing decisions, and how easily a buyer can replace that input without damaging those decisions.

An AI interface makes the boundary less visible

Now replace the analyst's screen with an assistant that reads data, performs calculations and writes a short answer. The interface looks simpler while the underlying chain grows harder to see. A human may receive only a sentence, although several systems processed the input before that sentence appeared.

For product design, retrieval, storage, model training, calculation and delivery to a customer should be mapped as distinct operations. This is a way to locate questions, not a claim that exchanges assign each operation a separate fee. Calling the entire chain an AI feature does not tell a buyer which rights it already has, which it needs, or which outputs it may distribute.

LME's derived-data guidance says manipulating or combining its data into derived information may require a licence; fees vary with the use case and category.

That is a reason to examine a transformed output, rather than treat transformation itself as proof of permission. An answer, score or chart can conceal a complicated dependency on an upstream feed. The economical design is the one that makes this dependency understandable before the service is scaled.

Costs also extend beyond inference. A hypothetical assistant budget includes data access, delivery, computation and checking the result. Reducing model costs does little if the workflow still retrieves information it does not need or cannot reliably date. Reusing a cached observation can reduce traffic, but it also introduces a freshness decision; it is not by itself evidence that a licence obligation has disappeared.

Reading the revenue line more carefully

The important asset in this model is a continuing place inside useful decisions. The accompanying discipline is the ability to measure that place without confusing people, connections, applications and outputs. A machine-heavy product could reduce human screens while expanding automated work. It could also consolidate many tasks into fewer contracted arrangements. Neither outcome follows from the AI label alone.

Data fees therefore offer a different view of an exchange's business from trade counts. They can illuminate the commercial reach of information after a market observation has been produced. To interpret them, however, readers need to understand the permission base and its pricing, not simply count how often the market traded. The same price can perform many jobs; a good analysis keeps those jobs visible.

This is economic and operational analysis, not legal advice. Actual permissions and charges require checking the relevant licence and product terms.