Barchart vs Rithmic: Delayed Analytics Data vs Trade-Grade Market Data

Open a free Barchart chart for the ES futures contract and a live-looking price ticks across the screen. Open a Rithmic-fed quote inside a funded account's trading platform and a price also ticks across the screen. To the eye, both look identical: a number, updating, next to a candle. That surface similarity is exactly why so many funded traders get burned by data they never actually checked. One of those numbers can be several minutes old. The other is wired directly into the same low-latency connection that places the order at the exchange. Confusing the two isn't a rounding error. It's the difference between doing research and pricing risk.

What is Barchart, actually?

Barchart is a market-data, financial-analytics, and media company. It sells charting tools, stock and futures screeners, news, quotes, and a range of data-feed and API products used by everyone from a retail trader building a watchlist to a developer embedding a chart on a third-party site to an institutional desk pulling structured historical data. What Barchart is not is a trade-execution venue. It does not route an order to CME Globex, ICE, or any other exchange matching engine. It shows you data about the market. It does not place you in the market.

That distinction matters because Barchart's own lineup spans a genuinely wide range of delay and cost tiers under one brand. The free charts and screeners that show up when you search for an ES futures chart are typically running on delayed, non-real-time-entitled data. Barchart marks these quotes on its own site with a visible "[D]" indicator, and its help documentation is explicit that unentitled quotes carry a stated delay window, citing a 10 minute delay, CST, for futures and forex without real-time entitlement, and a 15 minute delay for stocks. A separate product line, Barchart's OnDemand APIs and its lower-latency Stream feed, sells non-delayed data to developers and institutions willing to pay for real-time entitlement and clear Barchart's professional or non-professional subscriber checks. Same company, two very different products, and that gap is the entire subject of this article.

What is Rithmic, and why is it a different category of product?

Rithmic is not a charting site or a screener. It is trading infrastructure: a combined data-and-order-routing stack that distributes real-time market data and carries order instructions to the exchange over the same low-latency connection. A large share of US futures brokers and prop trading firms build their execution stacks on top of Rithmic specifically because it keeps market data and order routing on one connected pipe, instead of stitching together a charting feed from one vendor and an execution connection from another. For the deeper architecture, the site's dedicated look at how a Rithmic feed and order-routing stack actually works covers the plumbing in full. The point that matters here is simpler: Rithmic-fed data is the same data an order is executing against, not a separate, slower copy sitting next to it.

That also means Rithmic sits differently on the market-data depth spectrum than a casual chart feed does. A screener quote is frequently just a last-traded price, sometimes delayed, with no book behind it. A trade-grade feed typically carries fuller order-book depth, the kind of Level 1 versus Level 2 market data distinction that determines whether you can see only the best bid and offer or the stacked size sitting behind them. None of that context is decorative if you are actually working an order into a fast market, not glancing at a chart between meetings.

This is also part of why a large number of futures prop firms and brokers specifically standardize on Rithmic rather than letting each trader pick a data source. A prop firm's risk engine, its evaluation-stage price feed, and its funded-stage execution feed all need to agree on the same current price at the same moment, since a discrepancy between the price a risk engine uses to check a drawdown rule and the price a trader's platform displays creates exactly the kind of dispute nobody wants to have mid-trade. Standardizing the whole stack on one real-time, execution-tied source removes that disagreement at the infrastructure level instead of trying to reconcile it after the fact.

Why is trading off delayed data dangerous?

Delayed data is not fake data. It is real, accurate data that arrived late, and "late" is the entire problem. Here is a concrete, hypothetical illustration of what late actually costs in dollar terms on a single ES contract, using CME's own published contract specifications, not an invented figure.

Say a trader has a free, delayed ES quote open showing 5,000.00. That print is genuinely accurate. It is just several minutes old, consistent with the kind of delay windows Barchart itself discloses on unentitled quotes (its own documentation cites figures ranging roughly from 10 to 20 minutes depending on the specific product, covered in the next section). While that quote sits frozen at 5,000.00 on screen, a fast, news-driven move happens live in the market, and the real, current ES price is now 5,006.50. That is a 6.50 point gap between what the screen shows and what the market is actually doing right now.

Convert that gap into money using the E-mini S&P 500's exchange-published contract specifications: a minimum tick of 0.25 points worth $12.50, and a full multiplier of $50 per index point. Both routes have to agree exactly:

6.50 points / 0.25 points per tick = 26 ticks. 26 ticks x $12.50 per tick = $325.00.
6.50 points x $50 per point = $325.00.

Both calculations land on exactly $325.00 of pure pricing error, per contract, before the trader has even chosen a direction, a size, or a stop. Scale that to a 3-contract position and it is $325.00 x 3 = $975.00 of pricing error baked into the decision before the trade even starts. That is not a cosmetic rounding issue. That is the direct, quantifiable cost of mistaking a screenshot of the market for the market itself, and it scales linearly with size, which is exactly why it matters more the bigger the position gets.

It gets worse once you add order type into the picture. A trader placing a limit order at what looks like a good level relative to the delayed 5,000.00 print is really placing that order relative to a level the market left behind minutes ago. A stop placed the same way is not protecting against the risk the trader thinks it is protecting against, because the reference point it was measured from was never the live price to begin with. The error is not just in the entry. It propagates into every downstream decision, sizing, stop distance, and target, that was calculated off the same stale number.

A delayed quote is not wrong. It is just not talking about right now.

Why does the same vendor quote two different delay windows?

Here is the detail that trips up traders who think they have already accounted for delay: even within one vendor's own documentation, the delay figure is not a single fixed number. It depends on exactly which product you are looking at. Barchart's website help page states unentitled futures and forex quotes on barchart.com carry a 10 minute delay, CST. Barchart's separate OnDemand API FAQ states something different for a different product: intraday API data "may be delayed by up to 20 minutes" because results are cached server-side rather than streamed live.

Both of those figures are correct, documented, and current as of Barchart's own published pages at the time of writing. Neither one is wrong. What is wrong is assuming "Barchart data" means one fixed, memorizable delay you can mentally subtract and call it handled. A trader reading a quote off the website is on a different delay clock than a developer pulling from the OnDemand API, and both are on a different clock again from someone paying for Barchart's real-time OnDemand or Stream products. The lesson is not "distrust Barchart specifically." The lesson is that delay status lives at the product and endpoint level, not the company level, and that is true of essentially every data vendor a trader will encounter, not just this one. Always verify the current, specific delay figure on the vendor's own current documentation for the exact product and account agreement in use instead of relying on a number you remember from somewhere else.

The caching detail behind the OnDemand API's 20 minute figure is worth sitting with for a moment, because it explains why the number is not simply "however fast a computer can serve a request." A cached endpoint is, by design, storing a snapshot and serving that same snapshot to many requests before refreshing it, which is a reasonable engineering choice for an analytics product answering thousands of screener queries a minute. It is a poor foundation for an execution decision, not because the engineering is bad, but because the product was built to answer "what has this been doing," not "what is this doing right now."

Does Barchart offer real-time, trade-grade data too?

Yes, and this is the part that gets lost when people shorthand the whole topic as "Barchart bad, Rithmic good." Barchart's commercial market data services lineup includes non-delayed OnDemand APIs and a lower-latency Stream product built for developers and institutional clients who need current, not cached, data, and Barchart markets these specifically alongside enterprise and institutional customers. Getting access to that tier means clearing Barchart's professional or non-professional subscriber classification and paying the underlying exchange's own real-time data fees, the same kind of licensing gate every real-time futures data provider has to enforce, because the exchange, not the data vendor, sets the real-time distribution terms and fee structure.

So the honest comparison is not "company A versus company B." It is "which tier, at what delay, doing what job":

Notice that even Barchart's paid real-time tier still does not route orders anywhere. It solves the delay problem, not the execution-connectivity problem, which is the second axis traders miss: real-time and trade-grade are not perfectly synonymous either. Real-time data tells you the current price. Execution-tied infrastructure like Rithmic ties that current price directly to the pipe the order actually travels on, which matters the moment a fill needs to happen off the real, current book rather than a same-moment but separately sourced copy of it.

How do you check whether your feed is actually tradeable?

Before sizing or placing a live order off any quote, chart, or dashboard, work through a short checklist instead of assuming the number in front of you is current:

Look for an explicit delay marker first. Barchart marks unentitled quotes with a visible "[D]"; if you see that marker, or anything equivalent, on any platform, treat the number as informational, not tradeable. Second, confirm which specific product you are looking at, not just which company, since a vendor's marketing page, its website charts, and its paid API can each carry a different delay window, as Barchart's own documentation demonstrates. Third, confirm your account's actual real-time entitlement and professional or non-professional classification directly with the vendor and the relevant exchange, since these are account-specific and change periodically. Fourth, if you are charting through a third-party platform layered on top of a broker's or prop firm's data agreement, for example running TradingView charts against a funded futures account, confirm which underlying feed and delay status that integration is actually using, since the charting layer and the data agreement behind it are not always the same thing. Fifth, if a platform is quoting you a price used to size a stop or a limit order, ask directly whether that same price is the one the order will execute against, or a separately sourced display copy of it. Sixth, run the check specifically during a fast, high-volume window, such as a major economic release, rather than in a quiet overnight session, since a feed that looks perfectly synchronized when the market is barely moving can reveal a meaningful gap the moment volatility picks up and the underlying data has more distance to cover per second.

Is Rithmic-grade infrastructure worth the cost?

Here is the tradeoff, stated plainly instead of sold. Unified, execution-grade infrastructure like Rithmic's costs more than casual analytics data, and in practice most funded traders do not even choose it independently. The prop firm or broker's technology stack usually mandates a specific data-and-routing provider as a condition of the funded account, not something left to individual preference. That is a real constraint, not a hypothetical one. A trader generally cannot bolt Rithmic-grade execution connectivity onto a research habit built around a free screener; the funded account either runs on it or it doesn't, based on which firm's technology stack the trader is inside.

On the other side, free or cheap analytics-tier data is genuinely useful, not a lesser product to feel embarrassed about. Building a watchlist, screening for setups, checking a level after the close, reading news-driven context on a contract, all of that is exactly what delayed research data is for, and it is a legitimate reason products like Barchart's free tier exist and get used at real scale. The mistake is not using free data. The mistake is using it for the wrong job: pricing a live order in a fast-moving market, where a delay window measured in minutes turns directly into a dollar figure measured in hundreds, per the ES example worked through above.

So the honest answer is conditional. Execution-grade infrastructure is worth its cost if you are actually placing live orders, because the cost buys you exactly the elimination of that pricing-error scenario. It is not worth paying for if what you're doing is research and screening, where a free, clearly disclosed delay window is a perfectly reasonable tradeoff for zero cost. The failure mode is applying the wrong tier to the wrong job, not picking the supposedly wrong vendor.

It is also worth being honest about what execution-grade infrastructure does not fix. Paying for real-time, execution-tied data removes the specific pricing-error problem worked through in this article. It does not remove ordinary market risk, it does not guarantee a fill at a chosen price in a fast market, and it does not substitute for a trader's own risk management. A trader with a perfectly current, perfectly accurate feed can still take a bad trade. What real-time, trade-grade infrastructure buys is the removal of one specific, avoidable, quantifiable error, acting on a price that was never current in the first place, not a guarantee of good outcomes on top of it.

What should you actually do before you trade off a data feed?

Treat every quote in front of you as carrying an implicit question: is this the number an order would execute against, or a number describing the market from a few minutes ago? Free charting and screening tools, Barchart's included, answer that question honestly if you actually read their own disclosures. Unentitled quotes are marked delayed, with a stated delay window that varies by specific product and that is worth verifying directly on the vendor's current documentation rather than assumed from memory. Paid, real-time data products solve the delay problem for research and analytics use cases. Execution-grade infrastructure like Rithmic solves a different problem entirely, keeping the price displayed and the price an order fills against on the same connected pipe.

None of this requires memorizing vendor org charts or picking a side in a company rivalry that does not really exist. It requires one habit, repeated every time: before sizing or placing a live order, confirm the specific delay status and entitlement of the specific feed in front of you right now, not the general reputation of whichever company's logo happens to be on the chart.

Frequently asked questions