Periscøpe
// Guide

How to think about broker state in automated trading

Your broker, not your code, is the source of truth for positions, fills, and buying power. How to design around that and what to watch in live trading.

June 19, 2026

In a backtest, your software is the entire universe, it decides what fills, what your position is, and how much buying power you have. In live trading, that’s no longer true. Your broker is the source of truth, and your code is, at best, a well-informed observer. Designing around that distinction is one of the things that separates a system that survives live from one that doesn’t.

The core idea: the broker is authoritative

When you go live, the real answers to “what’s my position?”, “did that order fill?”, and “how much buying power do I have?” live at the broker, not in your program’s memory. Your strategy holds a model of that state, and the model can be wrong, because of latency, a fill you didn’t process yet, or an action taken outside your system.

The mental shift: treat your internal state as a hypothesis about the broker’s state, not as the truth.

Where your code and the broker can disagree

  • Positions. A fill happened at the broker before your system processed it. For a moment, your position model is stale.
  • Buying power. Your estimate and the broker’s number drift apart as orders work and fill. The broker’s figure is the one that governs whether your next order is accepted.
  • Open orders. An order you think is working may have been filled, cancelled, or rejected.
  • Out-of-band changes. Someone closed a position manually, or another process touched the same account.

Start flat, or know exactly what you’re starting with

A strategy that assumes it begins with no position will behave unpredictably if the account already holds one. Before a live run, either start from a known-flat account or make the strategy explicitly aware of the starting positions. A silent non-flat start is a classic source of “the strategy did something insane on the first bar.”

Buying power: advisory vs enforcing

There’s an important difference between checks that enforce and checks that advise. In research and paper, your system can hard-reject an order that exceeds buying power, because it owns the simulated account. In live, the broker is authoritative, your own buying-power figure is best treated as advisory, with the broker making the final decision. Knowing which of your checks are enforcing and which are advisory prevents nasty surprises.

What to monitor

  • The orders you submitted and their actual broker states.
  • Fills, so your position model stays close to reality.
  • Rejections, which often signal a buying-power or state mismatch.
  • Your advisory buying power against the broker’s behavior.

How Periscøpe surfaces broker state

Periscøpe is built around this reality. In backtest and paper, the risk and buying-power checks are enforcing, orders that don’t fit are rejected. In live, your broker is authoritative: Periscøpe routes orders to it and surfaces the orders, fills, and positions it reports, and shows buying power as an advisory figure with the broker as the source of truth. The point isn’t to pretend your software is in control of the account, it’s to give you the visibility to see, quickly, when your model and the broker have drifted apart.

Related
// Access

Run one strategy through Periscøpe.

We onboard in focused cohorts. Tell us what you trade and how you work. Live access is rolled out to select users on request.

We only use your email to contact you about access.

Read the docs →