Market data can be technically easy to retrieve and contractually restricted to display. An API key, a sample endpoint, or a consumer app does not automatically grant the right to republish quotes on a public website, lobby screen, conference wall, or customer product. Licensing is therefore a product requirement, not a final legal checkbox.

This guide is a practical overview, not legal advice. Terms vary by venue, vendor, asset class, geography, audience, and data product. Before deployment, review the governing agreements with the provider and qualified counsel. Build the interface and operating process around the rights you actually have.

Identify the data origin and the vendor

The company selling an API may not be the original owner or operator of every dataset in it. Market data often flows from trading venues or benchmark administrators through distributors, aggregators, and application providers. Each layer can impose terms, and the vendor agreement may incorporate exchange policies by reference.

Create a source map that lists the originating venue or administrator, the direct vendor, the product name, the fields used, and the intended displays. Do not rely on a generic note such as “prices from API.” Precise records make it possible to answer licensing, attribution, and incident questions later.

Product names matter

A provider may offer real-time, delayed, historical, reference, and derived products under different terms. The fields can look similar while the rights differ. Record the exact product and entitlement, not only the endpoint. When a vendor changes plans or migrates an API, verify that the replacement preserves the same display permissions.

CME Group’s data-services portal, for example, separates tools for licensing, compliance, billing, and active market-data permissions; it illustrates how distribution is managed as an ongoing service rather than a one-time download. Review the provider’s market data licensing and compliance resources for the products you actually use.

Distinguish display and non-display use

Display use generally means presenting data to a human, while non-display use can include algorithms, calculations, automated decisions, order routing, or other machine processing. Definitions vary. A system may have both: it calculates rankings on the server and then displays selected values to users.

Do not assume a display license covers every backend use or that a data-processing license covers public presentation. Describe the full flow—from ingestion through calculations, storage, alerts, and screens—during procurement.

Public, internal, and customer-facing are different

An internal employee dashboard, a private client portal, a public webpage, and a lobby sign can fall into different categories. A screen inside an office is not automatically “internal” if visitors, customers, or event attendees can see it. A password does not necessarily make a portal nonpublic if the service is offered broadly to customers.

Document audience, location, access control, expected user count, and device count. For signage, include every player or screen group. For websites and apps, include monthly users, concurrent sessions, or other metrics requested by the provider.

Professional and nonprofessional classifications

Some market-data programs distinguish professional from nonprofessional users and may require declarations. A public display cannot always inherit the classification of the person who built it. If the product supports logged-in users, entitlement may need to be evaluated per user or organization.

Design account and reporting systems only after understanding the required classification. Avoid collecting personal information merely because a prototype assumes it is needed; confirm the actual contractual requirement.

Real-time and delayed rights are separate

Delayed data may be easier to redistribute in some arrangements, but “delayed” is not synonymous with unrestricted or free. The permitted delay, attribution language, and audience can be specified. Real-time public display may involve additional agreements, fees, user reporting, or technical controls.

Place the required delay notice near the data. If the product changes from delayed to real time, update licensing, disclosures, monitoring, and support documentation together. A configuration flag should not silently change the legal category of the service.

Attribution is part of the layout

Providers may require names, logos, copyright notices, delay text, or specific disclaimers. Reserve space in the design from the beginning. A tiny footer that becomes unreadable on signage or disappears on mobile may not satisfy the required presentation.

Keep attribution tied to the relevant dataset. If a page combines several sources, explain which provider applies to which panel. Do not imply that one source endorses calculations or editorial content it did not produce.

Derived data needs a defined methodology

Applications often calculate percentage change, rankings, averages, indexes, heat maps, or alerts. Those outputs may be considered derived data under a contract, but the definition and rights vary. Some transformations remain subject to the source terms even when the original number is not shown.

Document every calculation, input field, update cadence, and output. Ask whether the derived result can be stored, redistributed, or used after the source agreement ends. Keep enough metadata to reproduce the calculation and explain it to users.

Avoid assuming “transformed” means unrestricted

Changing color, rounding decimals, or combining a value with a company name is presentation, not necessarily a new independent dataset. Likewise, taking an average of several venues may create licensing obligations for each input. Get explicit answers rather than designing around a hopeful interpretation.

Storage, caching, and history can have limits

A ticker often caches the latest value for reliability. A chart stores history. An RSS archive republishes old observations. Agreements may treat those activities differently. Define retention periods, backup handling, and what happens when the license ends.

If historical rights are not included, do not build a permanent archive from real-time messages simply because the database can store them. Separate operational caches from historical products and enforce retention in code.

Reporting and audit obligations affect engineering

Providers may require counts of users, devices, locations, or entitlements. They may audit records or require periodic declarations. Build identifiers and logs that can produce the required reports without reconstructing deployment history manually.

For signage fleets, maintain a registry of device, location, template, data product, and activation dates. For web products, record plan, entitlement, and audience category. Protect logs appropriately; licensing compliance does not remove privacy and security obligations.

Prototype with safe data

A design prototype rarely needs production real-time quotes. Use clearly fictional values, licensed sandbox data, or a small static sample. Label it as illustrative. This avoids accidental redistribution and makes tests deterministic.

Do not scrape consumer websites or copy quotes from screenshots to simulate a feed. Even a temporary demo can be shared publicly, indexed, or shown to customers. Establish a safe prototype policy before teams begin building.

Plan vendor and product changes

APIs close, fields change, providers merge, and contracts renew. Isolate the data adapter from the presentation so a source can be replaced without rewriting every page. Store provider-specific identifiers separately from your canonical instrument model.

Include a shutdown plan. If rights expire, the system should disable the affected feed, clear prohibited caches, and switch to an approved fallback. A graceful unavailable state is better than continuing display while contract status is uncertain.

Questions to bring to a provider

Prepare a written description and ask:

  • May the data be shown publicly on websites, apps, or physical screens?
  • Is the use real-time, delayed, historical, or derived?
  • Which countries, user types, and devices are covered?
  • What attribution and delay notices are required?
  • Are calculations, caching, alerts, and archives permitted?
  • What reporting, audits, or declarations apply?
  • Can subcontractors, hosting providers, or signage vendors handle the feed?
  • What must happen when the agreement ends?

Keep the provider’s written responses with the product records. Verbal assumptions are difficult to operate and audit.

Conclusion

Market-data licensing shapes source selection, architecture, disclosures, account rules, device management, and cost. Map the full data flow, identify the exact product, and confirm rights for every audience and channel. When those decisions are made early, the ticker can be designed honestly instead of retrofitted after a public launch.