What is a market data feed?

A market data feed is a service or delivery channel through which an application receives information about financial instruments and market activity. Depending on the source, it may provide current observations, delayed information, historical records, or a combination. A feed describes the data supplied and how it is delivered; it does not determine what an application should conclude from that data.

Feeds can be supplied by venues, brokers, data vendors, or other services. Coverage, definitions, update behavior, and terms differ. The same general label can describe substantially different sets of instruments, venues, fields, and timing, so evaluation starts by asking what information the feed actually represents.

What information can market data feeds provide?

The information available depends on the source and service. Common categories include:

  • Prices and quotes. A reported price or available buy and sell quotations, with the meaning and coverage defined by the provider.
  • Trades. Reports of transactions, which may include price, quantity, and a time or sequence marker.
  • Volume. Measures of activity over a period or associated with reported transactions, subject to the source's conventions.
  • Order-book information. At a conceptual level, displayed interest at selected price levels, where the service provides it. Depth and venue coverage can vary.
  • Reference and instrument information. Identifiers, trading status, contract descriptions, or other fields that help an application interpret observations.

These categories are not guaranteed to be present together. A feed may cover selected venues or instruments, provide only certain fields, or summarize rather than expose every underlying event. Readers should interpret each field using the provider's definitions rather than assuming similar labels mean identical data.

Streaming and request-based delivery

A request-based delivery model provides information after an application asks for it. For example, an application might request a current quote or a set of observations for a specified period. This can suit tasks that need information on demand or at intervals chosen by the application.

A streaming model sends a continuing sequence of updates after the application establishes a subscription or connection. This can be useful when successive observations matter, but the stream still has a defined scope, format, and service behavior. A connection can be interrupted, and providers can differ in how they represent updates or indicate gaps.

These models describe delivery patterns, not a universal ranking of quality. A request-based service can be adequate for a workflow that does not need continuous updates; a stream can be appropriate when ongoing changes are relevant. The important consideration is whether delivery behavior fits the application's purpose and how the provider documents timing and continuity.

Real-time, delayed, and historical data

Real-time data generally refers to observations delivered with a small delay relative to underlying activity, but the exact meaning and timing depend on the source and service. Delayed data is delivered later, sometimes under different access terms. Historical data consists of stored observations made available for a prior period. These categories are related but not interchangeable.

An application should understand when a value was observed, when it became available through the feed, and what time convention its timestamp uses. A displayed 'latest' value may still be delayed, aggregated, or scoped to selected venues. Lower latency is not automatically an advantage: the data requirement depends on the use case, and speed alone says nothing about whether an application interprets information correctly or produces a useful result.

Historical research has additional concerns about what information was available at each past decision time and how records were maintained. Those questions belong to Historical Data Integrity for Systematic Trading; this article focuses on data delivery as infrastructure.

Normalization and timestamps

A trading technology stack may receive information from more than one source. Normalization is the process of representing observations in a consistent format so that an application can interpret comparable fields across inputs. Examples include aligning instrument identifiers, units, timestamp formats, or names for similar data fields.

Normalization should not erase meaningful differences. Two sources may use similar field names while applying different definitions, venue coverage, or aggregation. An integration should preserve enough context to identify the source and interpret what was received rather than silently treating every value as equivalent.

Timestamps are a central part of that context. A time value may identify when an event occurred, when it was recorded, or when it was made available. Time zones, precision, sequence information, and clock differences can affect how observations from different services line up. The required treatment depends on the application; the key is to know what each timestamp means.

Coverage, continuity, freshness, and quality

Coverage describes which instruments, venues, fields, or time periods a feed includes. One source may cover more venues but provide fewer fields for a particular instrument; another may offer richer observations within a narrower scope. Broad coverage is only useful if it matches the application's requirements.

Continuity and availability concern whether the service can deliver data as expected over time. Planned maintenance, service interruptions, connectivity conditions, or source limitations can affect delivery. Freshness concerns how current an observation is for its intended use. A value can be well-formed but no longer representative of current conditions if it arrives late.

Data quality can involve missing or duplicated observations, inconsistent identifiers, unexpected values, or differences in how events are represented. These are infrastructure and integration considerations, not proof that a provider is generally reliable or unreliable. An application should know what service information is available and how to distinguish a valid update from one that is incomplete or outside its expected scope.

For live bot operations, stale-feed detection, alerting, and response belong in Market Data for Trading Bots. This guide stays at the broader feed and integration level rather than describing bot monitoring or recovery procedures.

How feeds fit into a trading technology stack

A simplified flow is: market source → feed service → interface or connection → application → research, display, or other downstream use. The feed supplies observations; the application receives and interprets them according to its purpose. That purpose may be analysis, charting, recordkeeping, an automated process, or another software function.

Feeds are often accessed through an API or another documented interface. The interface explains how software communicates with the service, while the feed concerns what market information is delivered and its coverage and timing. For interface concepts, see Trading APIs Explained.

A system may also pass data through validation or normalization components before other applications use it. Automated systems then have their own operational responsibilities; Trading Bot Architecture covers how bot components consume information and coordinate downstream tasks. The feed itself does not define a strategy, generate a trading decision, or handle an order.

How to evaluate a market data feed

Evaluation should begin with the application's information needs rather than a generic claim about speed or breadth. Useful questions include:

  • Coverage. Which instruments, venues, fields, and time periods are included, and what is excluded?
  • Definitions. How does the source define each field, event, quantity, and instrument identifier?
  • Delivery. Is information request-based, streamed, delayed, historical, or a combination, and what update behavior is documented?
  • Timing. What does each timestamp represent, and how are delays or time conventions described?
  • Continuity. What service status or interruption information is available, and what limitations are documented?
  • Integration. Can the application interpret formats, units, identifiers, and source context without conflating unlike observations?
  • Terms. What access, usage, redistribution, or account conditions apply to the data?

The right answers depend on what the application needs to observe. No single delivery model or source is universally best, and a feature comparison is incomplete without considering definitions, coverage, service terms, and integration requirements.

A hypothetical market data workflow

Imagine a hypothetical research application that receives quote and trade observations for a set of instruments from a data service. The feed identifies the instruments and provides timestamps and field definitions. The application checks that the incoming format is understood, preserves source and time context, and displays the observations for a researcher to review.

A second application might subscribe to a stream for ongoing updates, while a periodic report requests data at intervals. Both applications depend on the same basic questions: what the source covers, what an update means, and how delays or missing information are represented. The example illustrates data moving from source through a feed into applications; it does not prescribe a trading decision or a particular provider.

Limitations and practical trade-offs

A feed is only as useful as the match between its information and the application's needs. A wider instrument list may not compensate for missing fields; frequent updates may be unnecessary for a slower workflow; a stream may require different integration considerations from periodic requests. Differences in definitions and coverage can also make direct comparisons misleading.

A feed does not guarantee complete market visibility, uninterrupted delivery, or a particular outcome from the software that consumes it. Provider terms and capabilities change, and the integration must account for the source's documented limitations. Market data is one infrastructure input among several, not a substitute for strategy research or operational design.

Keep the layers distinct: market data feeds concern what information is delivered and how; APIs concern the software interface used to access services; bot data operations concern how an automated system consumes and monitors inputs; and historical-data research concerns whether past records support a valid study. The Trading Technology hub connects these infrastructure topics with related coverage.