Issues with the margin in a PCS

Alpaca Integration Applications
1

Hello fellow devs,

I’m hitting a margin/cost_basis calculation that appears to contradict your (Alpaca) own documented formula for multi-leg orders, and I’d appreciate if anyone can explain this to me… as I can’t find a pattern.

The order (rejected):

  • Order ID: c38b9d62-6a4e-4ca3-a28b-6068d9218d47
  • Timestamp: 2026-09-14T17:20:54Z
  • Type: Call credit spread, order_class: mleg, SPXW 0DTE (index option, European, cash-settled)
  • Leg 1: SELL SPXW260914C07635000 (sell_to_open)
  • Leg 2: BUY SPXW260914C07640000 (buy_to_open)
  • Width: 5 points, limit_price (credit): 2.15

The rejection:

"code": 40310000,
"message": "insufficient options buying power",
"cost_basis": "10400",
"options_buying_power": "3000"

Why this seems wrong — per your own documentation (Options Level 3 Trading → “How do we calculate order cost basis?”):

cost_basis = maintenance_margin + net_price

For this defined-risk 5-wide call credit spread:

  • maintenance_margin = strike_diff × multiplier = 5 × 100 = $500
  • net_price = −(2.15 × 100) = −$215 (credit received)
  • cost_basis = 500 − 215 = $285

Yet the order was charged $10,400 — roughly the margin of a naked short call, not a defined-risk spread. This is a $10,115 discrepancy from your documented formula.

Both legs are same underlying, same expiration, submitted together in a single MLeg order with covered legs — which per your docs should be recognized under the “universal spread rule” with margin capped at the spread width ($500).

My questions:

  1. Why is the maintenance margin being calculated as ~$10,600 instead of the $500 the universal spread rule specifies for a 5-wide spread?
  2. Is the short leg being treated as uncovered/naked despite the long protective leg being present in the same MLeg order?
  3. Does this behavior differ when the short leg is ITM at submission time? (SPX was ~7639 when the short 7635 strike was ITM.)

I can reproduce this and provide additional order IDs if helpful. I’d like to understand the correct expectation before scaling automated activity.

Thank you <3

2

Your original m-leg order succeeded and was not rejected by Alpaca. You had enough buying power when you submitted that order. Below is the 200 status response sent for that order.

{
"timestamp":"2026-09-14T17:20:54.197Z",
"httplog","ip":"209.227.238.181",
"method":"POST",
"status_code":200,
"path":"/gobroker/api/v2/orders"
"body":"{\"qty\": 1.0, \"type\": \"limit\", \"time_in_force\": \"day\", \"order_class\": \"mleg\",
 \"legs\": [
{\"symbol\": \"SPXW260914C07635000\", \"ratio_qty\": 1.0, \"side\": \"sell\", \"position_intent\": \"sell_to_open\"}, 
{\"symbol\": \"SPXW260914C07640000\", \"ratio_qty\": 1.0, \"side\": \"buy\", \"position_intent\": \"buy_to_open\"}], 
\"limit_price\": 2.15}",
"user_agent":"APCA-PY/0.44.0 Python/3.12.3",
"order_id":"c38b9d62-6a4e-4ca3-a28b-6068d9218d47",
}

However, the order was subsequently rejected by the execution partner. The rejection reason was Complex_order_outside_acceptable_price_range. It was not rejected because of insufficient buying power.

The issue with this specific order is that you entered a positive limit price of 2.15. When you expect a credit, the limit needs to be specified as a negative number. In this case, the limit should have been specified as -2.15. When the execution partner received the order, because you specified a positive value, that was interpreted as the maximum you would be willing to pay (ie the maximum debit), which was too far outside the current prices for these two contracts, and the execution broker rejected the order, thinking it may have been keyed in incorrectly (which it was).

The limit price for m-leg orders follows the same convention as the limit price for an equity order and represents the maximum debit you expect. Since you expected a credit, the sign needs to be reversed.

The buying power calculation is correctly handled as per the documentation. If there is another example where you feel it is not being handled correctly, please post back. You may, however, find all the issues resolved simply by ensuring the limit price is negative if you expect a credit.

1 Like
3

Hello Dan,

Thanks for the clear explanation — that fully resolves it. The real order’s only problem was the credit sign, which I’ve now corrected (negative for credits). Orders are executing correctly.

Appreciate the help — consider this closed!

Best regards :wink:

1 Like