Delayed vs Real-Time Market Data: How to Check Whether Timing Fits the Task

A market-data label such as real time or delayed is only the beginning of a timing assessment. You also need to know when the underlying event occurred, when your system received it, and when the displayed value was refreshed. These timestamps answer different questions. A recently refreshed page can still show an old observation, and a historical bar can be complete for its interval while arriving later than expected.

Nasdaq's APA service describes real-time publication and a separate publication delayed by 15 minutes. That is a service-specific example, not a universal delay for all markets. The workflow here is an original data-inspection framework, not a validated investment strategy. It helps establish whether an observation is timely enough for a defined research task, without treating faster delivery as proof of better investment decisions.

Primary-source context: Nasdaq: OTC Publication Service; Alpaca: Real-time Stock Data and Updated Bars.

A deliberate delay is part of the data product's stated delivery arrangement. Staleness means the observation is older than your workflow expects, perhaps because of an interrupted connection, a closed market, or an instrument with no recent eligible event. These conditions can produce similar-looking screens but require different explanations. Do not describe a stalled stream as delayed data without investigating the cause.

Write an expected timing rule for the task. A study using completed daily observations may not need intraday delivery, but it still needs a clear completion time and a method for handling corrections. A comparison intended to represent the same moment needs synchronized observations. Your timing rule should identify the relevant session and timezone, including how non-trading days are represented, rather than treating elapsed clock time as a complete description of data freshness.

A bar aggregates observations over an interval. Its timestamp may label the start or another defined point of that interval, depending on the feed. Reading the timestamp without understanding the convention can make an unfinished bar look complete. Record whether the interval is still open and when your system considers it available for analysis.

Alpaca's streaming documentation describes updated bars when late trades arrive. This provides a concrete reason to preserve the version of an observation used in a time-sensitive study. The practical lesson proposed here is to separate first received data from later corrected data where your task requires that distinction. A polished final historical record may differ from the information a live observer initially saw. Whether that difference matters depends on the question, but it should not remain invisible.

Imagine two fictional displays viewed at 14:30 UTC. Display A shows a price of 25.00 with an event timestamp of 14:29:58. Display B shows 24.80 with an event timestamp of 14:15:00 and a known delay. The difference is 0.20, but it is not evidence that one provider is inaccurate because the observations describe different moments.

For a like-for-like check, the researcher requests observations corresponding to the same event window, session, and price definition. If the values then agree, the original discrepancy was a timing mismatch. If they still differ, coverage or event-selection rules may require further investigation. All numbers and timestamps here are hypothetical.

Now suppose Display A stops updating at 14:29:58 while its page clock reaches 14:40. The page clock does not establish market-data freshness. The workflow marks the observation stale under its own stated rule and stops presenting it as a current comparison until the cause is understood.

Record the provider's delay policy for the exact product, the event timestamp, the receipt timestamp where available, and the display refresh time. Identify the timezone and session. For bars, record the interval convention, completion rule, and treatment of subsequent updates. Distinguish no eligible new event from a failed data request.

Set a task-specific freshness boundary and explain why it is appropriate. Label values outside that boundary instead of silently carrying them forward. When comparing sources, align event windows before comparing numbers. Preserve the original observation used in a decision record if later corrections would change the interpretation.

Include a visible status such as complete session, delayed observation, stale, or timing unknown. These are descriptive states for the proposed workflow, not quality grades. A deliberately delayed but clearly labeled observation can be entirely adequate for some research tasks.

Use a hypothetical event occurring at 10:00:00 UTC. A fictional service makes it available at 10:00:02, a local process receives it at 10:00:05, and a dashboard displays it at 10:00:09. The interval from event to display is nine seconds. In this constructed example, two seconds precede service availability, three more precede local receipt, and four more precede display. The decomposition is useful because shortening the final refresh interval would address only one part of the total. It would not remove an earlier delivery delay.

Write each timestamp into a timing worksheet and retain its provenance. A server-supplied receipt field and a timestamp generated by your own process are not interchangeable simply because they use the same format. The worksheet should identify which clock produced each observation and whether their alignment is known. If the local receipt appears earlier than the event, investigate clock alignment, timezone conversion, and field meaning before reporting negative latency. An arithmetic difference between timestamps is interpretable only when their definitions and clocks support that comparison.

Add the moment at which the researcher actually used the observation. If the same record is consulted at 10:05:00, it is then five minutes old relative to its event, even though initial delivery took nine seconds. That distinction separates pipeline performance from the freshness of a later analysis. For repeated inspections, preserve both quantities. A fast pipeline can display an old eligible event, while a slow pipeline can eventually deliver a complete record suitable for retrospective work. Neither case can be classified responsibly using only a green connection indicator or the word real-time in a product label.

Consider a hypothetical research dashboard that compares recently observed prices during a chosen session. Its author sets an illustrative maximum event age of sixty seconds. At 11:00:00, records timestamped 10:59:20 and 10:58:30 are forty and ninety seconds old. The first passes the author's freshness rule; the second does not. Sixty seconds is a chosen requirement for this example, not a market standard, a provider guarantee, or a boundary at which information becomes economically useful. The rule exists so the interface does not imply simultaneity it cannot support.

Now suppose the second instrument has no newer eligible transaction, while its connection continues to receive heartbeat messages. The transport may be functioning even though the latest trade is old. Keep separate fields for connection health, last received message, and last eligible market event. A feed heartbeat should update the connection status without updating the trade's timestamp. Otherwise the dashboard converts evidence of a functioning connection into a false statement about the age of a price. Conversely, an old event alone does not prove that the connection has failed.

The worksheet should include session status, intended event type, expected update behavior, maximum age, and action when the requirement is not met. Actions might include hiding a comparison, showing an age label, or using a completed historical interval instead. Define the treatment of closed sessions and instruments with sparse observations before inspecting a convenient example. Avoid silently relaxing the rule until every row passes. If the intended task cannot tolerate the available observations, changing the task is clearer than making the freshness threshold progressively less meaningful while keeping the original description.

Imagine a hypothetical one-minute interval covering 09:30:00 through the moment before 09:31:00. The fictional provider labels it 09:30:00. Its first completed version arrives at 09:31:03 with a close of 100.20 and volume of 1,000 shares. A corrected version arrives at 09:31:20 with a close of 100.10 and volume of 1,100. These are invented records used to explain version handling, not an account of any provider's actual processing timetable. Both versions refer to the same interval, but they were not available at the same time.

A research decision recorded at 09:31:10 could use the first version under a rule that accepts it on arrival. It could not use the corrected version that arrived ten seconds later. A retrospective chart seeking the latest known interval record might instead use the correction. Neither task should erase the distinction. Store the interval identifier separately from receipt time and version. If a row is keyed only by its interval label and overwritten, the historical information state disappears even though the resulting table still contains neatly spaced timestamps.

A useful worksheet asks four questions: which interval does the row describe, when was this version received, when did the analysis consume it, and was another version substituted afterward? Reconcile a sample decision against those answers. If the study deliberately waits thirty seconds after interval end, specify whether it accepts the newest version received by that deadline or waits for another completion signal. A waiting rule may change which corrections are included, but it cannot establish that no further correction will arrive. Present the chosen rule as a reproducible research convention with an explicit limit.

Suppose two hypothetical feeds are inspected at 13:00 UTC. One supplies events through 12:59:59 and another through 12:45:00. Comparing their latest prices tests a mixture of delivery timing and price evolution. To investigate numerical agreement, choose a common historical window supported by both. Record the intended observation within that window, such as the latest eligible transaction at or before 12:45:00. Then align identity, coverage, and event-selection rules before interpreting a remaining difference. A shared wall-clock display time is not an alignment procedure.

Even a common cutoff needs an age rule. Imagine Feed A's eligible event occurs at 12:44:59 and Feed B's at 12:42:00. Both satisfy the cutoff, but they remain observations from different moments. A backward lookup can make every row complete while concealing that gap. Add each event's distance from the cutoff and any tolerance used to permit the comparison. If a compatible event is unavailable, retain the missing result. Do not use the nearest later event simply because it is closer in elapsed time; that would change the historical information boundary.

For a practical comparison worksheet, include requested cutoff, chosen event time, value, event definition, coverage, and reason for exclusion. Summarize aligned observations separately from unmatched ones. If most mismatches occur in sparse instruments, report that concentration rather than treating the average discrepancy as representative of every use case. The outcome may be that both sources are adequate for completed daily summaries but cannot support the same intraday comparison. That is a useful task-specific conclusion without asserting that either feed is universally accurate, inaccurate, faster in every circumstance, or suitable for execution.

A hypothetical dashboard loses its connection at 14:02 and reconnects at 14:07. Receiving one new event proves that a message has arrived; it does not reconstruct the missing five minutes. If the task requires a continuous interval history, recovery needs an explicit gap record and a method for obtaining the absent observations. If the task only displays the latest eligible event, a different recovery rule may be sufficient. Define these requirements separately so a latest-price update does not silently mark an incomplete historical chart as complete.

Suppose a recovery request returns records already received before the interruption alongside missing records. The research workflow needs a stable way to identify duplicates and subsequent versions. Otherwise summing the combined volume could count some activity twice. This is an original process-design example: the correct identifiers and correction rules must come from the actual feed definition. Preserve recovery status until the intended interval is reconciled. A connection indicator may turn healthy before the history required by a particular calculation is ready for use.

Add a recovery worksheet with interruption start, reconnection time, affected instruments, missing intervals, replacement source, duplicate treatment, and unresolved gaps. Record which displayed calculations depended on the incomplete interval and when they were refreshed. A stale warning should disappear because the relevant task requirements are satisfied, not merely because the application restarted. If recovery cannot establish a complete interval, keep that limitation visible in exports as well as on screen. This prevents a screenshot or downloaded table from appearing more timely or complete than the information that actually supported it at the moment of use.

Real-time access does not guarantee complete coverage, correct adjustments, uninterrupted delivery, or an executable price. A latest trade is an observed transaction, not a promise that another transaction can occur at the same value. Faster updates also do not validate a research hypothesis or compensate for misunderstanding the field being displayed.

Delayed data are not automatically unsuitable for research, but a workflow must not imply immediacy that it does not have. The useful distinction is fitness for the stated task. Document the timing assumptions, expose stale states, and align comparisons. Once those steps are complete, you can describe what the data represent without turning a delivery label into a claim about analytical quality or investment opportunity.