Hunting 'Ghost Positions': The F-160 Rule and Defensive Design in System State Reconciliation

It was 1:15 AM, and the trading system was running its routine midnight checks. Suddenly, the logs lit up with a series of critical warnings. The position_monitor had detected active, highly leveraged positions on the exchange—specifically, a 75x leveraged 1000PEPEUSDT long and a 20x leveraged ETHUSDT long.

There was just one massive problem: our internal system had absolutely no record of opening them.

In the high-stakes world of algorithmic crypto trading, these are known as "Ghost Positions." If left unchecked, our AI trading engine would assume these were its own trades and attempt to apply automated Take Profit/Stop Loss (TP/SL) logic. The result? Catastrophic, unauthorized interventions on trades the system didn't originate, potentially liquidating manual positions or triggering disastrous margin calls.

This post-mortem explores how defensive state reconciliation and strict execution rules—specifically the F-160 Iron Rule—prevented a potential financial disaster, and the architectural philosophy that makes it possible.

Background: The Illusion of Perfect Synchronization

In algorithmic trading, we operate under the assumption that the internal state (our database) and the exchange state (the broker's reality) are perfectly synchronized. When the AI decides to open a trade, it sends an API request, records the OPEN state internally, and manages the lifecycle.

However, in production environments, perfect synchronization is a myth. Exchange APIs experience latency, webhooks get dropped during network blips, and human operators occasionally log into the exchange's web UI to manually adjust hedges or take speculative shots. When these external factors occur, the exchange state diverges from the internal ledger. If the system blindly trusts the exchange state, it will inevitably act on data it doesn't fully understand.

The Problem: The Anatomy of a Ghost Position

A "Ghost Position" is an active position on the exchange side that lacks a corresponding internal OPEN record in our algorithmic ledger.

During a routine RECONCILE phase, our system compares the real-time exchange state against the internal ledger. Here is what the logs captured when the ghosts appeared:

2026-11-11 01:15:54,636 [WARNING] position_monitor: RECONCILE: Unrecorded position 牛来USDT LONG@0.0839 (10x) — treating as manual (no OPEN record) 2026-11-11 01:15:54,637 [WARNING] position_monitor: RECONCILE: Unrecorded position ETHUSDT LONG@2240.05 (20x) — treating as manual (no OPEN record) 2026-11-11 01:15:54,637 [WARNING] position_monitor: RECONCILE: Unrecorded position 1000PEPEUSDT LONG@0.0047 (75x) — treating as manual (no OPEN record)

These positions could exist for several reasons:

  1. Manual UI Trading: The operator manually opened a position via the exchange interface while the bot was running.
  2. API Desyncs: A network partition caused the bot's order to fill on the exchange, but the internal database failed to record the OPEN event.
  3. External Interventions: A sub-account or external script modified the position.

The danger is immediate. The AI's execution engine sees an open position and naturally attempts to manage it. If it applies its automated TP/SL logic to a manually opened 75x leveraged meme coin position, it could prematurely close a winning manual trade, or worse, execute conflicting orders that violate the exchange's margin requirements.

The Solution: Defensive Reconciliation & The F-160 Iron Rule

To prevent catastrophic automated interventions, we rely on a two-pronged defensive mechanism: Defensive Reconciliation and the F-160 Execution Guardrail.

Defensive Reconciliation in the RECONCILE Phase

The position_monitor logic is designed to be inherently suspicious. When it compares the real-time exchange state against the internal ledger and finds a discrepancy, it does not guess. It does not attempt to "adopt" the position into the algorithmic strategy. Instead, it applies a critical design choice: flag the discrepancy as 'manual' with a safe default.

The F-160 Iron Rule Execution Guardrail

Flagging the position is only half the battle; we must also prevent the execution engine from acting on it. This is where the F-160 mechanism comes in. F-160 acts as a hard circuit breaker.

When the system processes these flagged positions, F-160 explicitly checks if the position is in the approved manual list or if it has specific algorithmic markers (like CAT_ conditional orders). If it lacks these, F-160 triggers:

2026-11-11 01:15:54,637 [WARNING] position_monitor: F-160: ETHUSDT not in manual list and no CAT_ orders - treating as MANUAL (safe default)

Consequently, the execution engine applies the F-160 iron law, bypassing all automated TP/SL logic for these unregistered positions:

"error": "Manual position (unknown (F-160 safe default)) - skipped auto TP/SL per F-160 iron law" "error": "Manual position (known manual) - skipped auto TP/SL per F-160 iron law"

The Result: The AI trading system successfully maintains strict isolation between its own algorithmic strategies and external/manual market activities. The ghost positions are safely ignored by the automated engine, preserving system stability and preventing disastrous automated overrides.

Technical Details: State Isolation Architecture

The F-160 rule is not just a standalone script; it is a manifestation of a deeper engineering principle: State Isolation Architecture.

In our system, we strictly separate the intent of the algorithm from the reality of the exchange.

  1. The Internal Ledger is the Single Source of Truth for Actions: The algorithmic engine only reads from and writes to the internal database. If a trade is not explicitly recorded in the internal ledger with an OPEN status, the algorithmic engine is mathematically prohibited from executing management logic (TP/SL, trailing stops, scaling) on it.
  2. The Exchange State is a Read-Only Reality Check: The exchange API is used strictly for verification and execution routing. We poll the exchange to ensure our internal orders were filled, but we never allow the exchange state to directly mutate the algorithmic decision tree.

This isolation is layered with other defensive mechanisms visible in our logs. For instance, when the system encounters technical anomalies or missing data, it doesn't crash or guess; it defaults to safe states. We see this in the scoring engine's elastic thresholds adapting to consecutive vetoes, and in the hard-veto mechanisms rejecting trades when multi-timeframe percentiles are misaligned:

2026-11-11 01:15:52,326 [INFO] scoring_engine: F-229/F-230: Elastic threshold: 75 → 70 (consecutive_veto=239, original=80, floor=60) 2026-11-11 01:16:43,636 [INFO] adv_trend_direction: [F-ADV-PCTB-HARD-VETO] HYPEUSDT SHORT rejected: 15m,1h,4h pctb={'15m': 10.03, '1h': -15.12, '4h': -8.23}

By treating the internal ledger as the absolute authority for algorithmic actions, we ensure that the AI can never accidentally manage a trade it didn't conceptualize.

Lessons Learned: Building Reliable AI Trading Systems

Hunting ghost positions reinforces a fundamental truth in quantitative engineering: robust state management and defensive guardrails are non-negotiable for production-grade systems.

When building AI trading infrastructure, it is tempting to optimize for "happy path" execution—assuming APIs will always respond, databases will always sync, and operators will never touch the manual UI. But production systems live in the "sad path."

Designing for failure means implementing "fail-secure" mechanisms rather than just "fail-safe" ones. When the F-160 rule triggered, it didn't just fail safely by doing nothing; it actively secured the system against a specific class of catastrophic errors by enforcing strict state isolation.

Building resilient algorithmic infrastructure requires anticipating these edge cases and hard-coding the boundaries of the AI's authority. Discover more about building resilient algorithmic infrastructure and production-grade trading systems at https://kestrelquant.com.

⚠️ Risk Warning

Defensive system design mitigates technical and systemic errors but cannot eliminate market risk. Handling ghost positions prevents automated disasters, but manual or external positions still carry full market exposure. Algorithmic trading involves substantial risk of loss; never deploy capital you cannot afford to lose. The architectural patterns discussed in this article are for educational and engineering purposes and do not constitute financial advice.

Tags: #algotrading #crypto #ai #buildinpublic