What is a market data feed

What a market data feed is

Markets produce prices continuously. Every time a trade prints on an exchange, or a dealer moves a two-sided quote in the currency market, the price of an instrument changes. A market data feed is the pipe that carries those changes from the places where prices are formed to the systems that need to display or use them.

The important word is continuous. A feed is not a page you reload or a file you download once a day. It is an open connection over which the provider sends new prices the moment they arrive, without the client having to ask for each one. On a quiet day a feed may deliver a few updates per minute for an instrument; around a major economic release it can deliver many updates per second for the same instrument.

A modern feed usually covers several asset classes at once. The FinaQuotes feed, for example, carries stocks, crypto, forex, metals, commodities, indices and bonds in one normalized format, so a client connects once and subscribes to the instruments it needs. The full list of supported markets is on the coverage page.

Market data feed vs market data API

The two terms are often used as synonyms, but they describe different delivery models. A market data API in the narrow sense works on request and response: the client sends a request such as "give me the latest price of EURUSD" or "give me the last 500 hourly candles", and the server answers once. If the client wants a newer price, it has to ask again.

A feed works on push. The client opens a connection, says which instruments it is interested in, and from then on the server sends every relevant update without further requests. This removes polling, reduces load on both sides and, most importantly, removes the gap between the moment a price changes and the moment the client learns about it.

In practice a production integration uses both. Live prices arrive over a streaming connection, usually WebSocket, while history, the instrument catalog and other reference data are fetched over a REST API. The WebSocket vs REST guide covers how the two fit together, including what to do after a disconnect.

What a tick contains

The tick is the unit of a feed. Formats differ between providers, but a useful tick always answers three questions: which instrument, at what price, and when.

• Symbol. A stable identifier of the instrument, such as a currency pair, a stock ticker or a crypto pair. The provider maps every source symbol to its own naming so that the client sees one consistent identifier.
• Price. Either a two-sided quote (bid and ask) or a single last price. In the FinaQuotes feed, forex, spot metals and US stocks carry two-sided bid/ask; crypto, indices, commodities and bonds carry the last price, so in the tick bid = ask = last. The bid, ask and spread guide explains why.
• Timestamp. The moment the price was recorded, in UTC. A single time zone across all asset classes removes a whole category of bugs around daylight saving time and exchange-local clocks.

Some feeds add more fields, such as volume or exchange codes. The minimum above is what a client needs to show a live quote, compute a spread and append the price to a chart.

Normalization: one format for every asset class

Prices for different markets originate in very different places. Equities print on exchanges with their own message formats. Currencies are quoted by dealers and liquidity venues. Crypto trades on venues that run around the clock. Each source names instruments differently, uses its own precision and sends updates in its own schema.

Normalization is the work of turning all of that into one consistent stream. A normalizing provider maps source symbols to a single naming scheme, converts timestamps to UTC, applies consistent price precision per instrument and delivers every asset class in the same message shape. FinaQuotes data is aggregated from multiple institutional and exchange data sources and normalized by FinaQuotes, so a client does not need a separate adapter for every market.

For a broker the value is practical. One parser, one symbol table and one set of tests cover forex, metals, stocks and crypto. Adding a new asset class becomes a subscription change rather than a new integration project.

Candles are derived from ticks

A chart rarely shows raw ticks. It shows candles: for each period, the opening price, the highest price, the lowest price and the closing price (OHLC). Candles are not a separate kind of market data; they are computed from the tick stream.

In the FinaQuotes feed the base timeframe is one minute. Higher timeframes, from 5 minutes up to one month, are aggregated from it, and all candle boundaries are aligned to UTC. The feed provides 9 timeframes: 1m, 5m, 15m, 30m, 1H, 4H, 1D, 1W and 1MN. History is available over REST, with years of daily history and months of intraday; see historical data for the depth per timeframe.

The details of how candles are built, including exchange sessions and how to handle late updates to the latest candle, are in how candles are built from ticks.

Who uses a market data feed

The same feed serves very different roles. What changes is how the data is used and how strict the requirements are.

• Brokers show quotes to clients in their terminals and apps, compute the spread a client sees and draw charts. They need real-time data, two-sided prices where the market is quoted that way, and a provider that keeps running when one source fails. See market data for brokers.
• Trading platforms and prop firms need a stable stream for many instruments at once, consistent candles for charts and history for analytics.
• Financial websites and publishers show tickers, quote tables and small charts next to their content. For them a short delay is often acceptable, and embeddable quote widgets are usually a better fit than a raw feed.

How to evaluate a feed provider

Comparing feeds by the length of the instrument list alone is misleading. The questions below tell you more about how the feed will behave in production.

• Latency. How long after the provider receives a price does it reach you? Ask for the delivery model, not just a number. Also separate data latency from display refresh: a widget that redraws every few seconds can still be fed by sub-second data.
• Coverage and quote type. Which asset classes, which instruments within them, and is each one real time or delayed? Is the price two-sided bid/ask or a last price? A clear table per asset class is a good sign; the FinaQuotes table is on the market data policy page.
• Fallback. What happens when a source goes silent or sends bad values? A feed with several independent sources per asset class and automatic fallback keeps prices flowing. Ask whether instrument silence is monitored.
• History. Which timeframes are available, how deep is the history, and is it in UTC?
• Delivery and limits. Is there a streaming protocol with a documented reconnect procedure? Are REST requests rate limited, and how are limits signalled? The documentation should answer this before you sign anything.
• Licensing and redistribution. Exchange data comes with rules about display and redistribution. Clarify what you may show, to whom and with what delay. This guide is not legal advice; check terms with the provider and, where needed, with your own counsel.

A longer checklist for brokers is in how to choose a market data provider.

Mini glossary

A few terms that appear in every conversation about feeds. The full list is in the market data glossary.

Frequently asked questions