Account, Position, and Buying-Power Semantics

Direct Answer

The numbers your broker reports for account equity, buying power, and open positions do not derive from the same calculation your internal state machine uses. Brokers apply regulatory requirements, margin haircuts, settlement timing, and open-order holds that your system can't fully replicate in real time. Treating your internal cash balance as ground truth for order sizing decisions is a common cause of over-leveraging, margin call orders being rejected, and subtle P&L discrepancies.

The correct approach is to treat the broker's account and position endpoints as the authoritative source for sizing decisions, and to use your internal state only for latency-sensitive real-time decisions between synchronization events. This means syncing the broker's reported values at specific checkpoints, session open, after fills, and periodically throughout the day, and never allowing internal state to diverge from broker-reported values for more than a configurable tolerance.

Key Takeaways

  • Buying power ≠ cash balance: Buying power is derived from your equity after applying margin rules, open order holds, and settlement timing. Never compute it from cash alone.
  • T+1 and T+2 settlement create "unsettled" funds: Stock sales settle in T+1 in US markets (since May 2024). The proceeds are available for trading immediately in a margin account but restricted in a cash account until settlement.
  • Open orders reduce buying power immediately: When you submit a limit buy for $10,000 of stock, that $10,000 is held against your buying power the moment the order enters the broker's order book, before the fill, before the settlement.
  • Margin multipliers vary by account type and position: A Reg-T margin account provides 2:1 leverage for overnight positions and 4:1 intraday leverage in some configurations. Portfolio margin accounts use risk-based calculations that can be higher or lower. Crypto margin varies by exchange.
  • Position cost basis depends on accounting method: Your broker may use FIFO, LIFO, or specific-lot matching for cost basis. This affects unrealized P&L reporting. Your system needs to match the broker's method or accept discrepancies in P&L calculations.
  • Sync before sizing decisions: Before computing the size of a new order, query the broker's current buying power if more than N minutes have elapsed since the last sync, where N depends on your trading frequency.
  • Maintenance margin triggers differ from initial margin: A position can exceed the maintenance margin threshold after a price decline and trigger a margin call, even if initial buying power checks passed when the order was submitted.
  • Crypto positions include unrealized funding payments: On perpetual swap exchanges, open positions accumulate or pay funding every 8 hours. These funding cash flows affect your effective account balance in ways that don't appear in simple position × price calculations.

Core Concepts

Buying Power Calculation: What Brokers Actually Compute

Buying power is not a single value, different brokers expose it as multiple fields that each answer a slightly different question. Alpaca's account object exposes buying_power (total day-trade buying power for a margin account, typically 4× equity for PDT-eligible accounts), cash (settled cash), portfolio_value (market value of all positions plus cash), and equity (portfolio value minus any outstanding margin loan balance). IBKR exposes NetLiquidation, BuyingPower, ExcessLiquidity, AvailableFunds, and others, each measuring a slightly different slice of the account.

The key formula for a standard Reg-T margin account: Buying Power = (Equity × Margin Multiple) - (Open Long Positions Market Value) - (Value of Open Buy Orders). For a $50,000 equity account with 2× margin, $60,000 in open longs, and $5,000 in pending buy orders, buying power = ($50,000 × 2) - $60,000 - $5,000 = $35,000. The open orders hold is the most commonly missed term: your buying power is reduced the moment you submit a buy order, even before it fills.

Under PDT rules (Pattern Day Trader, for US accounts with less than $25,000 equity), intraday buying power reverts to 2× equity from 4× as soon as the account is marked as a PDT account and equity drops below the $25,000 threshold. This reduction can occur mid-day if losses bring equity below the threshold. Your system needs to either monitor this dynamically or accept that the broker's buying_power value is already adjusted for current account state.

To test your buying power model: run the broker's calculation formula against a known account state from a real account statement and compare your computed value against the broker's reported buying_power. If they differ, the discrepancy reveals an assumption mismatch. Common sources of discrepancy: forgetting to subtract pending order holds, not applying the correct margin multiple for the account type, or using unsettled proceeds as if they were settled.

Settlement Mechanics and Their Effect on Available Funds

US equity trades now settle T+1 (trade date plus 1 business day) following the SEC's 2024 rule change from T+2. This means if you sell $10,000 of AAPL on Monday, the $10,000 proceeds appear in your account immediately but are "unsettled" until Tuesday morning. In a margin account, these unsettled proceeds are generally available for new purchases immediately (the margin account temporarily covers the gap). In a cash account, using unsettled proceeds to buy before they settle constitutes a free-ride violation, which FINRA can restrict your account for.

For automated trading systems, the settlement distinction matters primarily in cash accounts used for tax-advantaged accounts (IRAs, 401k self-directed) where margin is not permitted. In these accounts, the system must track which funds are settled and which are unsettled, and ensure new buy orders are only sized against settled funds. The broker's API typically exposes both cash (total) and cash_withdrawable or settled_cash (settled only), use the settled value for cash-account buy sizing.

Options trades settle T+1 (same as equities since May 2024). Futures trades settle T+1 at most exchanges. Crypto trades typically settle immediately (T+0) on the exchange, though transfers to/from the exchange may have their own settlement delays. Know the settlement cycle for every asset class you trade and factor it into your available-funds calculation.

Test settlement mechanics by executing a sell, then immediately attempting to buy with the full proceeds in a cash account, and verifying whether the broker rejects the buy (correct behavior) or accepts it (broker is not enforcing free-ride prevention at the API level, leaving compliance to you). Record the broker's behavior in your capability manifest.

Position Semantics: Lots, Cost Basis, and Mark-to-Market

A position in your system is typically represented as: symbol, quantity (signed, positive for long, negative for short), and average entry price. The broker represents the same position with additional fields: market value (current price × quantity), unrealized P&L (current market value - cost basis), realized P&L (from closed portions of the position), cost basis (depends on accounting method), and in some APIs, individual lot details showing the acquisition date and price of each lot.

The accounting method for cost basis, FIFO (first in, first out), LIFO (last in, first out), or specific-lot identification, affects unrealized and realized P&L calculations. Most US brokers default to FIFO for equities. If your system uses a different method for its internal P&L calculation, the broker's reported unrealized P&L will diverge from yours. This is not an error, it's an expected discrepancy from different accounting choices. Document which method each broker uses and align your internal calculation to match, or accept the discrepancy and reconcile at the tax lot level.

Short positions have additional complexity. A short position requires borrowing shares, which incurs a borrow rate (short interest rate) that reduces your effective P&L daily. The broker's API reports the current short exposure (negative position quantity) and the current market value, but may or may not include the accrued borrow cost in the daily P&L. Check whether your broker's unrealized_plpc (unrealized P&L percent) field includes borrow costs or reports pure price-change P&L.

Options positions add delta, gamma, theta, and vega as position-level attributes that your system may need to consume for portfolio risk analysis. Not all broker APIs expose Greeks on open option positions, some require a separate market data call to compute them. If your strategy uses delta-neutral hedging, verify that the broker's position API provides or can derive the Greeks you need, or plan to compute them independently from option pricing models.

Reconciling Broker State with Internal State

Position reconciliation is the process of comparing your system's internal position model against the broker's authoritative position record and resolving any discrepancies. Run reconciliation at minimum once per trading session at a fixed checkpoint (e.g., 15 minutes before the close), and additionally after any reconnect event. The reconciliation process: fetch all positions from the broker's positions endpoint, compare each against your internal position map, classify discrepancies, and resolve them.

Discrepancy types to handle: (1) Position in broker but not internal, a fill was missed. Find the fill in the broker's activity log and apply it. (2) Position in internal but not broker, an order that your system thought was filled was actually canceled or rejected. Remove the position from internal state and investigate why the fill event was incorrectly processed. (3) Quantities match but cost basis differs, different accounting method or a corporate action (dividend, split, spinoff) that adjusted the position. These require human review.

Corporate actions are a particular challenge: stock splits, reverse splits, spin-offs, and dividends in the form of additional shares all change position quantities and cost basis at the broker level without a corresponding fill event. If your reconciliation logic assumes position changes can only occur via fills, corporate actions will appear as unexplained discrepancies. Subscribe to the broker's corporate action notification feed if available, or check for the standard adjustment messages that some brokers send as pseudo-fills.

Alert on any reconciliation discrepancy that cannot be automatically resolved. A discrepancy larger than $100 notional or more than 1 share (for equities) should trigger an alert and halt automated trading in that symbol until a human reviews and resolves the discrepancy. Never automatically close or open a position to force reconciliation, you may be creating more errors by doing so.

Worked Scenario

  1. Account state. Your margin account has $75,000 equity. The broker reports buying_power = $150,000 (2× equity for overnight positions). You have $60,000 in open long positions and $12,000 in pending buy orders.
  2. Broker's actual buying power. $150,000 - $60,000 (current long market value) - $12,000 (open buy order holds) = $78,000 available for new buys.
  3. Your internal calculation error. Your system computed available buying power as $75,000 × 2 - $60,000 = $90,000, forgetting to subtract the $12,000 pending order hold.
  4. Consequence. Your strategy signals a $85,000 buy. Your internal check passes ($85,000 < $90,000). The broker rejects with "insufficient buying power" (85,000 > 78,000). The order was never submitted correctly, the strategy position logic didn't account for the rejection, and the position state diverges.
  5. Fix. Before computing order size, query the broker's account endpoint and read buying_power directly. Use the broker-reported value, not your internal calculation. This query takes 80ms but prevents the $85,000 rejection and its downstream state confusion.
  6. Better fix. After each order submission, re-sync buying_power from the broker's account endpoint. The broker has already applied the order hold; your cached value reflects reality. For a trading system that submits orders infrequently, this per-submission sync is the simplest correct approach.

Measurement Framework

MeasurementQuestion to Answer
Buying power reconciliation delta ($)How large is the discrepancy between your internal buying power and the broker's reported value at each sync?
Position quantity discrepancy eventsHow many reconciliation cycles discover a position quantity mismatch between internal and broker state?
Order rejections due to insufficient buying powerHow many orders are rejected because the system used stale buying power values for sizing?
Unsettled funds utilization (cash accounts)Is the system attempting to trade against unsettled proceeds in cash accounts?
Cost basis discrepancy rateWhat fraction of positions have a cost basis discrepancy between internal and broker records, indicating an accounting method mismatch?

Common Failure Modes

Ignoring Open Order Holds in Buying Power

The most common buying-power error is computing available capital as equity × margin multiple and forgetting to subtract the value of pending buy orders. A system with $100,000 equity and 2× margin has $200,000 of theoretical buying power, but if there are $150,000 in open buy orders, only $50,000 is actually available. Submitting a $75,000 buy against this account results in a rejection.

Person counting dollar bills over documents with a smartphone calculator on the desk.
Photo by Tima Miroshnichenko via Pexels

Query the broker's buying_power field rather than computing it internally. The broker has already applied all holds, pending orders, and margin rules. Use that value as your sizing constraint, not a derived approximation from equity × multiple.

Using Unsettled Proceeds in a Cash Account

A strategy that sells securities and immediately reinvests the full proceeds in a cash account (IRA, Roth IRA) is using unsettled funds. Brokers flag this as a free-ride violation. After three violations in a rolling year, many brokers restrict the account to settled-cash-only trading for 90 days. This would halt all automated activity in the account.

Track settlement status for each fill event. For cash accounts, maintain a settled_cash counter that only increases when the T+1 settlement date passes. Size new buy orders against settled_cash, not total_cash. Most brokers expose a separate settled_cash or cash_available_for_withdrawal field that reflects only fully settled funds.

Missed Corporate Action Causing Position Quantity Error

A 4:1 stock split quadruples the share count in the broker's position record overnight. If your system's position tracking doesn't receive a corporate action notification, it wakes up the next morning with a position of 100 shares while the broker shows 400 shares. Any order submitted based on your internal 100-share record will be wrong relative to the actual exposure.

Run end-of-day position reconciliation every trading day, comparing against the broker's positions endpoint, not just relying on intraday fill event processing. Corporate actions appear as quantity changes overnight; the reconciliation will detect them and alert for human review.

Not Accounting for Maintenance Margin Calls

An account that passes the initial margin check when an order is submitted can subsequently fail the maintenance margin requirement if position prices decline. Maintenance margin for standard equities is 25% under FINRA Rule 4210, but brokers often set higher "house" requirements. If positions decline enough to bring margin equity below the maintenance requirement. The broker issues a margin call, requiring the account to either deposit funds or liquidate positions within a short window. A system that doesn't monitor for margin calls may attempt to buy more while the account is in margin call, leading to order rejections or forced liquidations at bad prices.

Monitor the broker's maintenance_margin and excess_liquidity or equivalent fields in the account object. Alert when excess_liquidity falls below a warning threshold (e.g., 20% above the required maintenance level). Halt new buy orders when excess_liquidity approaches zero or when the broker explicitly reports a margin call status flag in the account object.

FAQ

How often should my system sync with the broker's account endpoint?

Sync at session open, after every fill, and on a periodic timer (every 5-15 minutes for actively trading systems, every 60 minutes for lower-frequency systems). For position sizing decisions specifically, always use the most recently cached broker-reported buying power value, if the cache is more than a configurable staleness threshold (e.g., 10 minutes) old, query fresh before computing a new order size. The extra 80ms to query the account is worth it to avoid a rejection from stale sizing logic.

What's the difference between equity, net liquidation value, and portfolio value?

These terms are used interchangeably by some brokers and distinctly by others. In common usage: portfolio value is the sum of all position market values plus cash (before accounting for any margin loan). Net liquidation value is portfolio value minus any outstanding margin loan (what you'd receive if you liquidated everything and paid back any borrowed funds). Equity is typically equivalent to net liquidation value. Always check your specific broker's field definitions, Interactive Brokers uses NetLiquidation as the primary equity measure, while Alpaca uses portfolio_value and equity as separate fields.

How does T+1 settlement affect an automated strategy that trades daily?

For margin accounts, T+1 settlement has minimal practical impact, margin accounts can use unsettled proceeds immediately with the broker's own funds bridging the settlement gap. For cash accounts (including IRAs), T+1 means if you sell on Monday, the proceeds settle Tuesday morning. If your strategy sells Monday and wants to reinvest on Monday afternoon, it must either wait until Tuesday or the strategy must be structured to only reinvest within the same day's settled cash balance. High-frequency cash-account strategies must explicitly track the settlement date of each sale and restrict reinvestment accordingly.

Why does my broker show a different unrealized P&L than my internal calculation?

Common reasons: (1) Different cost basis accounting method, FIFO vs. LIFO vs. specific lot; (2) Corporate actions that adjusted cost basis at the broker level but weren't reflected in your internal records; (3) Your broker marks options to mid-price rather than last price; (4) Your system uses a different pricing source (different data feed) than the broker's internal valuation; (5) For short positions, your system may not be accruing the daily borrow rate cost that the broker includes in its P&L calculation. Identify which cause applies and either align your calculation method or document the known discrepancy amount.

What is a "house" margin requirement and how does it differ from Reg-T?

Regulation T (Reg-T) is the Federal Reserve's minimum initial margin requirement for stock purchases: currently 50% (you must put up at least 50% of the purchase price, borrowing at most 50%). FINRA sets minimum maintenance margin at 25%. But individual brokers can set "house requirements" that are stricter than the regulatory minimums. Interactive Brokers, for example, applies its own risk-based models that often require more than 50% initial margin for volatile or concentrated positions. Check your broker's house requirements, which are typically listed in their margin documentation or accessible via the API's initial_margin_req and maint_margin_req fields per position.

How does a crypto exchange determine buying power for leveraged positions?

Crypto perpetual swap exchanges use mark price (not last-trade price) for margin calculations to prevent liquidations from brief price spikes on thin books. Your effective buying power on a leverage position is: (Initial Margin × Leverage) - Open Position Notional - (Funding Payments Accrued). Funding payments, which are paid or received every 8 hours based on the difference between the perpetual price and the spot index, affect your effective cash balance continuously. The exchange's account API typically exposes available_balance (what you can use for new positions) separate from wallet_balance (total deposited amount). Use available_balance for sizing decisions.

What should I do if my position reconciliation discovers a discrepancy I can't explain?

Halt automated trading in the affected symbol immediately. Do not attempt to resolve the discrepancy by submitting orders, you may be creating additional errors on top of the original one. Query the broker's transaction history or activity log for the symbol over the last 24 hours. Cross-reference against your internal fill event log. Common unexplained discrepancies: a fill event that arrived during a WebSocket gap (not reconciled after reconnect), a corporate action (split, dividend), or a manual trade placed through the broker's web interface rather than the API. Once the cause is identified, apply the correction manually and document it. Re-enable automated trading after confirming internal and broker state match.

Can I use the broker's position endpoint as my system's primary position store?

No, and for two reasons. First, the broker's position endpoint reflects settled state that may lag real-time fills by seconds to minutes depending on the broker's data pipeline. Your intraday risk management needs to reflect fills immediately as they are confirmed, which requires your internal fill event processing pipeline, not periodic REST queries. Second, broker REST endpoints add network latency and rate limit cost to every read. Your internal state should be the low-latency, high-frequency position store, with broker REST as the periodic authoritative sync to detect drift. Use the broker as the source of truth for the periodic reconciliation, not for real-time position management.

What does a working order do to reported buying power before it fills?

Most brokers reserve the notional value of an unfilled buy order against available buying power at submission, releasing the reservation on cancellation or adjusting it on a fill. A system that tracks buying power only from filled positions will therefore disagree with the broker while orders are resting, and the disagreement grows with the number of open orders. Modeling reservations explicitly, and treating the broker figure as authoritative rather than reconciling only on fills, avoids submitting orders that are then rejected for insufficient funds.

References

Educational Disclaimer

This guide is for educational and informational purposes only. It does not constitute financial, investment, legal, or tax advice. Margin requirements, settlement rules, and account semantics vary by broker, account type, and jurisdiction. Always verify current rules with your broker and consult a licensed professional before implementing automated trading systems.