Rithmic Historical Data: What You Can Actually Backfill, and Why Your Chart Is Empty

You open your funded account, connect the platform, and the footprint chart is empty. Or it starts drawing forward from the second you logged in, with nothing behind it. Or the platform surfaces something cryptic — rp_code=["13", "permission denied"].

Your software is not broken and your password is not wrong. You have hit an entitlement wall, and this article explains exactly where it sits, why it exists, and what you can actually do about it.

Rithmic is not one connection — it is four

This is the part that makes the whole thing click. When a platform "connects to Rithmic", it is not opening one session. Rithmic's R | Protocol splits the service into separate plants, each with its own login, its own heartbeat, and — crucially — its own entitlement:

• Ticker plant — live market data. Trades, quotes, depth. This is the one your firm definitely pays for.
• History plant — historical replay. Past ticks, past bars. This is the one that is often missing.
• Order plant — order routing and your working orders.
• PnL plant — your positions and account balance.

You can be perfectly authenticated on the ticker plant — live data flowing, chart ticking, everything green — and be flatly refused by the history plant with the same credentials. That is not a contradiction. It is two different products, and your account was only sold one of them.

What rp_code 13 actually is

Rithmic answers every request with a response code. 0 is success. 13 is permission denied: the request was well-formed, your login was accepted, and the answer is still no.

When you see it on a history request, it means precisely one thing: this account is not entitled to that historical product. No amount of retrying, reconnecting, or reinstalling changes it.

The two ways to fetch history, and why one survives the wall

There is more than one way to ask Rithmic for the past, and they are not entitled identically:

• Tick replay — asks for the individual trades, then rebuilds the bars locally. This gives you a true footprint, because every trade still carries its aggressor side. It is also the heaviest request in the protocol, and the one most likely to be walled off.
• Volume-profile bars — asks Rithmic to send pre-aggregated bars that already carry a per-price bid/ask breakdown. Much lighter, and on some accounts it is entitled when raw tick replay is not.
• Time bars — plain OHLC. No footprint possible: the bid/ask split was thrown away before you received it. Useful only to fill gaps.

This ordering matters in practice. Our platform tries volume-profile bars first and falls back to tick replay, precisely because we found accounts where the lighter request went through and the heavier one did not. If your platform only implements one path, you may be told "no history" when history was actually available.

What we found across the firms

The honest answer is that this varies by firm, by account type, and by month — firms change their entitlements without announcing it. So rather than publish a table that will be wrong by next quarter, here is what we have actually observed, and how to check yours in a minute:

• Funded accounts generally fare better than evaluations. The firm is already making money on you.
• Simulated / paper accounts are the most likely to have no historical entitlement at all. This is the classic "free demo, no history" combination — you get the live CME feed and nothing before it.
• Being denied is not permanent. We have seen the same login entitled for historical ticks after the firm enabled the add-on. It is a switch on their side, and if enough of their traders ask, they flip it.

How to check in sixty seconds: connect, and try to load a chart for a session that has already closed — yesterday, or this morning if it is now the afternoon. If bars appear, you have historical entitlement. If the chart only fills forward from now, you do not. That is the whole test.

What you can do about it

There are exactly three real options, and one of them is free.

1. Ask your firm to enable it

Ask specifically for historical tick data on Rithmic, not just "historical data". Support desks route the vague question to the wrong team. It is an entitlement on your account, it costs them, and they will only do it if asked. It is also, by a distance, the best outcome: canonical data, straight from the exchange, no gaps.

2. Let your platform build its own history (free)

Every bar your platform constructs from the live feed can be written to a local cache. Leave it connected during the session and it accumulates its own history, session after session. It is not retroactive — it cannot give you last week — but after a fortnight you have a fortnight. This is what we do, and it is why a Senzoukria chart on an unentitled account still has context after a few days instead of staying blank forever.

3. Buy the data elsewhere

CME tick data is a commodity and you do not have to buy it from Rithmic. Independent vendors sell it per-symbol, per-day. It is a paid, deliberate step — but if you are building a serious backtest, you were going to need it anyway.

What this means for your chart

A platform that cannot backfill has two honest choices: show you an empty chart, or tell you why. Ours says it plainly in the interface — "no history returned by the broker for this login" — and then fills forward from live data rather than pretending. A blank screen with no explanation is how you end up blaming your software for a bill your prop firm chose not to pay.

If you want the wider picture — feeds, rules, drawdown — the pillar of this cluster is Order flow on a prop-firm account. And if your bars simply do not agree with your broker's, that is a different problem with a different cause: start with how delta is built.

Nothing here is financial advice. Entitlements and prop-firm rules change without notice — verify with your own firm before relying on any of this.