Position Reconciliation in Automated Trading

By Stax Team

Reconciliation means comparing what your software believes it holds against what the broker actually reports, and treating the broker as authoritative. It matters because state drifts for reasons your system never initiated: partial fills, early assignment, broker auto-liquidation, expired orders, and ambiguous submissions. A system acting on stale state makes every subsequent decision on a wrong number, and the error compounds rather than staying contained.

Reconciliation is the least glamorous part of trading automation and the one that separates a system that works from one that works until it does not.

Why state drifts

Not through bugs, mostly. Through ordinary events your system did not cause.

Partial fills. An order for ten fills four. A system keying off submitted quantity now believes it holds a position it does not.

Assignment. A short in-the-money American-style option can be assigned before expiry, producing a stock position that appears without any instruction from you.

Broker auto-liquidation. Many brokers close positions when an account falls below required levels, at whatever price is available. Your broker's risk logic operates independently of yours and takes precedence.

Expired orders. A day order expires at the session boundary — which for futures is the daily maintenance break rather than midnight. A system that believes a protective order is working may have none.

Ambiguous submissions. An order that timed out may or may not have landed. Until you ask, both are possible.

Expiration. Positions resolve at expiry, in cash or in shares depending on the product, without your system doing anything.

Every one of these is normal. None is an error condition. All of them leave your system's picture wrong.

What acting on stale state costs

The error compounds through every subsequent decision rather than staying where it started.

Exits size wrong. A system that submitted ten and exits ten while holding four is not closing a position — it is opening a short one for the difference.

Risk limits enforce against fiction. Position counts and exposure calculations run on quantities that are wrong, so concurrency caps and capital ceilings are checked against numbers that do not describe the account.

Protective orders cover the wrong amount. A stop sized to a position larger than you hold opens exposure when it triggers.

Entries stack. A system that believes it is flat will open a position it already has.

Each of these produces a position nobody decided to take, which is the specific failure automation is supposed to eliminate.

What to reconcile

Positions. Instrument, quantity, and side per position. The core comparison.

Working orders. Which orders actually exist at the broker, in what quantity, at what price. A system that assumes its brackets are in place should confirm it.

Balances and buying power. Available capital drives sizing, and it changes with fills, assignment, and margin adjustments.

Per-leg quantities on multi-leg positions. A spread is not one quantity. Partial fills leave legs unequal, and reading the package total hides it.

When to do it

On every restart, before doing anything else. A process that reloads and acts on assumed state is the most reliable way to produce a duplicate position. Nothing should trade before the first reconciliation completes.

On a schedule during the session. Frequency depends on how fast being wrong becomes expensive. A short-dated options strategy has less tolerance than a swing strategy.

After any ambiguous outcome. A timeout, a dropped connection, a rejection you did not expect. Query rather than resubmit — resubmitting an order that already landed doubles the position.

After known state-changing events. Session boundaries, expirations, and any roll. These are scheduled, so reconciling around them is cheap.

Handling a discrepancy

Finding one is the easy part. Deciding what to do is where systems differ.

The broker is authoritative, always. Not a starting assumption to be weighed against internal state — the answer. Your system's belief is a cache, and the cache is what is wrong.

Correct the internal picture first, then decide. Update state to match, then evaluate whether the new reality requires action. Acting before correcting compounds the error.

Alert on anything unexplained. A discrepancy you can attribute to a partial fill is routine. One you cannot explain means something happened you do not understand, and a human should look before the system trades again.

Consider halting on large discrepancies. A small quantity mismatch is worth correcting silently. A position you did not know about is worth stopping for.

What this means for implementation

Treat quantity as a value read from the broker, not one your system owns. That single reframing removes most of this category, because it stops the system from having a belief to be wrong about.

Persist state outside the process. A system that recomputes from current conditions on restart has silently reset its own measurements, including any high-water marks and daily counters.

Keep it off the order path. Reconciliation is periodic, potentially slow work involving several broker calls. It must not delay a live submission, which is the worker thread pattern applied to housekeeping.

Log both pictures on every discrepancy. What you believed and what the broker reported. Diagnosing a state problem from memory is not possible.

On a self-hosted deployment the schedule, the alerting, and the halt thresholds are all yours to configure, which means they exist only if you configure them.

The honest limits

Reconciliation is detection, not prevention. It finds drift after it has occurred, and there is a window between the event and the next check in which the system is wrong.

Reconciling more often narrows that window and costs requests against APIs whose rate ceilings are frequently unpublished. There is a real trade-off rather than a free improvement.

And it does not improve a strategy. It prevents a class of avoidable loss that has nothing to do with whether the strategy works. Position sizing bounds what the remaining errors cost — capital divided by twenty as the ceiling on any single position, under the divide-by-20 rule.

Frequently asked questions

What is reconciliation in trading automation? Comparing what your software believes it holds against what the broker reports, and treating the broker as authoritative.

Why does state drift? Partial fills, assignment, broker auto-liquidation, expired orders, ambiguous submissions, and expirations all change positions without your system initiating them.

How often should I reconcile? On every restart before trading, on a schedule during the session, after any ambiguous outcome, and around session boundaries and expirations.

What if my system and the broker disagree? The broker is right. Correct internal state first, then decide whether the new reality requires action.

Can reconciliation prevent drift? No. It detects drift after the fact, which is why the window between checks matters.


Disclaimer: This article is educational content about trading software and mechanics. It is not investment advice, financial advice, tax advice, legal advice, or a recommendation to buy or sell any security, nor a recommendation of any platform, broker, or strategy. Competitor features, pricing, and terms described here reflect publicly available information as of publication and change frequently; verify against each vendor's current official sources before making a decision. Options and futures trading involve substantial risk of loss and are not suitable for all investors. Please read Characteristics and Risks of Standardized Options before trading options. Automated trading carries additional risks including software defects, connectivity failures, broker API changes, and outages that may prevent orders from being placed, modified, or cancelled. Past performance does not indicate future results, and no platform, configuration, position-sizing rule, or risk setting can guarantee a profit or prevent a loss.

StaxInvesting LLC sells self-hosted trading software. It is not a broker-dealer, investment adviser, or financial institution, and it does not manage accounts, hold member funds, place trades on behalf of members, or access member brokerage accounts. Members run the software in their own cloud environment, connect their own brokerage accounts under their own credentials, and are solely responsible for their configuration, their credential security, and every trade executed in their account. Broker handling, approval levels, and available features vary; verify against your broker's current documentation. Consult a qualified financial adviser and tax professional regarding your individual circumstances.