How TradingView Simulates Order Fills: Broker Emulator and Bar Magnifier
A Strategy Tester trade is not a historical order sent to a real broker. TradingView’s Broker Emulator creates simulated fills from available chart data, order type, creation timing, gaps and intrabar assumptions. Bar Magnifier can use lower-timeframe data to refine the sequence inside a chart bar, but it does not reconstruct every tick, order-book queue, partial fill or network delay. This guide audits why a fill occurred on a particular bar and price before any profitability metric is trusted.
Who this guide is for: Strategy users puzzled by stop or limit fills, developers reviewing same-bar entries and exits, and traders comparing simulations with and without Bar Magnifier
Key points to understand first
- The Broker Emulator simulates strategy fills from chart data; it is not an archive of real brokerage executions.
- Historical bars use OHLC and intrabar path assumptions, while a price crossed through a gap follows separate fill logic.
- Market, limit, stop and stop-limit orders separate creation, activation and execution in different ways.
- Bar Magnifier improves granularity where lower-timeframe coverage exists but does not guarantee complete coverage or real-market fills.
- A defensible fill record names order creation, activation, the available path or lower-timeframe coverage, and the fill time.
The order of prices inside one bar can change the fill
A strategy marker records a simulated Broker Emulator fill
A TradingView strategy creates order commands, then the Broker Emulator simulates a fill on the next available tick or when a price condition becomes eligible. The condition bar, order-creation time and visible fill marker need not be identical. Reconcile order type and creation bar with the List of Trades instead of reading the marker alone.
This is a repeatable historical simulation, not automatic recovery of the broker’s queue, spread, latency, rejection, partial fills or price improvement. A Tester fill at 104 is not proof that a live account would have received 104 at that time.
An OHLC history requires an assumed intrabar path
OHLC identifies four points reached during a bar but not every tick between them. The Broker Emulator applies documented rules to infer an open-high-low-close or open-low-high-close path. When both entry and exit levels sit inside one range, this ordering can change whether an exit was reachable after entry.
| Issue | Question | Unsafe shortcut | Evidence |
|---|---|---|---|
| Range | Is the order inside high-low? | Inside means guaranteed fill | O/H/L/C and order price |
| Path | Which level is traversed first? | Assumed path equals real ticks | Inferred sequence |
| Gap | Is price between prior close and open? | Fill at the requested level | Prior close and current open |
| Same bar | Is exit reachable after entry? | High and low prove the order | Creation and fill sequence |
A touched price does not prove sufficient liquidity for the entire order in a real market.
Fill explanation = order type + creation time + activation price + available path + fill ruleCoverage ratio = audited fills with lower-timeframe coverage / audited sampleThis audits explainability, not the error against a real fill.Separate four failure boundaries. A price touched before the order existed is not fill evidence. A gap between the prior close and next open does not prove that every intermediate level traded. A bar containing both entry and exit prices still needs an after-entry path. A limit order also requires its current verification rule and active lifetime, not merely a visible touch.
Separate market, limit, stop and stop-limit behavior
A market order asks for execution at the next available opportunity without a target price. A limit constrains the acceptable price. A stop activates after its trigger and then behaves as its defined order type. A stop-limit adds a limit condition after activation. A chart touching a line therefore means different things for each order.
| Type | What must happen after creation | Audit focus |
|---|---|---|
| Market | Next available tick | Creation versus fill bar |
| Limit | Eligible limit price | Touch/trade-through, gap, unfilled case |
| Stop | Activation then execution | Separate trigger and fill |
| Stop-limit | Stop activation plus limit eligibility | Activated but unfilled case |
Confirm current behavior in TradingView’s official Strategies and Broker Emulator documentation.
A close-confirmed strategy that creates a market order can display its fill around the next bar’s open under standard behavior. Explain this as condition confirmation, creation, then next available tick—not merely as a “late signal.”
Use lower-timeframe detail, then measure its actual coverage
Bar Magnifier lets the emulator consult available lower-timeframe data instead of relying only on the chart bar’s default path. If lower-timeframe bars show an entry followed by an exit level inside one chart bar, a same-bar exit can appear where the default path did not allow one.
Lower-timeframe requests have a historical limit, so early portions of a long chart can lack coverage. Plan, symbol, chart interval and available lower intervals matter too. Record not just that Magnifier was enabled, but which audited trades were actually inside its covered region.
| Field | Evidence to retain | Treatment when missing |
|---|---|---|
| Audit span | First/last chart bar and trade IDs | Separate covered from unknown |
| Lower interval | Actual interval and symbol identifier used | Do not invent a tick path |
| Order timeline | Creation, activation and fill bar/time | Quarantine unresolved trades |
| Comparison version | Identical fingerprint except Magnifier off/on | Reject multi-change runs |
| Missing history | Unavailable interval and count | Keep it in the coverage denominator |
Coverage proves the granularity behind a simulated fill, not the fill that a live venue would have delivered.
Make the order type and Magnifier premise visible in source
The Pine v6 sample creates a fictional buy stop after a confirmed cross and, after a position exists, places stop and limit exits. `use_bar_magnifier = true` records the intended premise, but feature availability and historical coverage still require an environment check. The EMA and tick distances are teaching values, not recommended orders.
//@version=6
strategy(
"Intrabar fill audit demo",
overlay = true,
use_bar_magnifier = true,
calc_on_order_fills = false,
process_orders_on_close = false
)
float basis = ta.ema(close, 20)
bool setup = ta.crossover(close, basis) and barstate.isconfirmed
if setup
float entryStop = high + syminfo.mintick
strategy.entry("L", strategy.long, stop = entryStop)
if strategy.position_size > 0
float protectiveStop = strategy.position_avg_price - 10 * syminfo.mintick
float target = strategy.position_avg_price + 20 * syminfo.mintick
strategy.exit("L-X", "L", stop = protectiveStop, limit = target)
plot(basis, "EMA", color.orange)When comparing Magnifier off and on, freeze every other property and chart field in the TV11 fingerprint.
Source alone still cannot explain every fill. Reconcile the List of Trades entry/exit bar and price with chart OHLC, coverage and order-creation evidence. If `calc_on_order_fills` or `process_orders_on_close` changes, pair the comparison with TV15’s execution audit.
Try to falsify the surprising fills one trade at a time
| Object | Evidence to save | Question to disprove |
|---|---|---|
| Target trade | ID, entry/exit time, price, direction and size | Which single fill is being explained? |
| Order creation | Condition, bar and order type | Did the order exist before the fill? |
| Price path | Prior close, OHLC, gap and inferred sequence | Could the path reach the level in that order? |
| Magnifier | Lower-timeframe coverage and off/on difference | Does the fill depend on the default path? |
| Unresolved | Missing-data, unverified-rule or market-mismatch flag | Was an unknown replaced with a convenient story? |
Keep an unexplained field visible instead of inventing a tick path.
Start with assumption-sensitive trades: same-bar entry/exit, gaps, a limit touched once and the early history of a long dataset. Preserve versions whose performance deteriorates; they reveal which results depended on optimistic fill assumptions.
Freeze a window containing the target trades, run the default-path version, then rerun with Bar Magnifier under the same source hash and Properties. Export the same trade-list format from both and reconcile from the first diverging ID. Reopen the same chart context on another date and confirm that coverage start, creation time and fill price still support the same explanation. Use unresolved and uncovered counts as the release gate rather than selecting the more profitable run.
Audit fills before sending result data to the Lab
Once every challenged fill has an explanation and the Bar Magnifier coverage is recorded, open the Backtest & Robustness Lab with the matching fill-audit export in CSV or XLSX format. Compare equity paths, drawdowns and trade distributions across Magnifier-off, Magnifier-on and conservative-fill fingerprints. Paid saved analysis becomes useful when those like-for-like fill versions must remain available for repeated comparison.
Free indicators can support signal observation, but an indicator does not automatically generate strategy orders or Tester trade data. Define the order rules in a strategy and finish the fill audit first. Bar Replay, Paper Trading and the Broker Emulator expose different limitations rather than replacing one another.
Count lower-timeframe coverage and assumption-sensitive fills
Enter audited fills, fills inside Bar Magnifier coverage, same-bar entry/exit cases and gap crossings. The output organizes review work; it does not estimate live-fill error.
Coverage = min(B,A)/A; default-path fills = max(A-B,0); sensitive cases = C+D. Cases can overlap, so this is not a unique-trade count or real-market accuracy rate.
Frequently asked questions
Does the Broker Emulator reproduce real broker fills?
Not completely. It simulates fills from chart data and documented rules; it does not automatically recover the real order book, queue, latency, partial fills or rejection.
Does Bar Magnifier turn a backtest into an exact tick backtest?
No. It uses available lower-timeframe data for more granular intrabar processing, but it is not a complete tick or microstructure reconstruction and coverage is limited.
Is a limit order guaranteed when the bar touches its price?
Do not assume so. Check current limit-fill settings, gaps, creation timing and the lower-timeframe path. Real-market liquidity remains separate.
Why does a market-order marker appear on the bar after the signal?
When a standard strategy evaluates at bar close and creates the order there, the earliest fill is the next available tick, commonly the next bar open. Record any process-on-close change as a different execution contract.
Primary sources and verification links
- TradingView | Broker emulatorOfficial overview of simulated execution and related settings
- TradingView Pine Script | StrategiesOfficial Broker Emulator, order types and Bar Magnifier manual
- TradingView | What is Bar Magnifier backtesting modeOfficial lower-timeframe, same-bar fill and coverage explanation
- TradingView Pine Script | Declaration statementsOfficial use_bar_magnifier and calculation/fill argument reference
- TradingView Pine Script FAQ | StrategiesOfficial FAQ for order timing, Bar Magnifier and testing
Edited and published by: SG Group · Editorial approach: We prioritize official TradingView Help Center and Pine Script documentation, then use exchange, regulator and other primary materials for market and product context. Features, data, pricing and connection terms change, so verify the current interface and linked sources before use.
Important notice: This article provides general education about TradingView interfaces, charts, alerts, screeners, paper trading and Pine Script. It is not investment advice, a trading signal, a recommendation of any instrument, data source or broker, or a guarantee of future price or profit. Features, pricing, data, exchange coverage, notifications, order integrations and Pine Script behavior vary by plan, region, connection and date and may change. Before risking money, verify current TradingView documentation and the terms of the relevant data source and connected provider, then rehearse the workflow with fictional data or paper trading.

