"Order rejected: Credit spreads cannot equal or exceed the strike difference"

Broker rejected accepting a put spread combi order by giving this reason:
"Order rejected: Credit spreads cannot equal or exceed the strike difference.|Credit spreads cannot exceed the strike difference."
In other words: "Spread trade credits cannot exceed the width of the strikes"

I think this is a bug b/c one can easily imagine valid combinations, for example this one:

Code:

Spot=100, DTE=90
Short Put: Strike=100, Premium=23.42 (IV=120)
Long Put:  Strike=90,  Premium=10.47 (IV=80)

Here the NetPrice is 23.42 - 10.47 = 12.95, which of course exceeds the width of the strikes (100-90=10).

Comments?

What is the correct formula to use for "NetPrice" for such a combi spread order?
After getting the above error, I came up with this formula, but am not sure:

Code:

  NetPrice = min(S.Strike - L.Strike - max(S.ticksize, L.ticksize), S.MyAskOffer - L.MyBidOffer);

where S is the Short leg and L the Long leg of the spread, and NetPrice positive for credit spread and negative for debit spread.

 

Just like what the message says, your option combo price is the same or larger than the difference in strike prices of the options in the combo. If the strike between the two options in the spread is only 3 for example, you shouldn't be paying more than 3 for them when you are closing the position nor are you allowed to charge more than the spread difference.

 

Just piss off you @TheDawn idiot with your usual incompetence!

 

Put in separate orders.

 

This is not a bug.
It's the way it's working and your example doesn't make sense at all.
Some US Options Exchange validate the price of spread orders.
See here for one example (BOX Options Exchange): https://rules.boxexchange.com/browse
and search for "IM-7240-1".

 

Yeah, that's the solution to this funny problem.

 

Why do you think the given example doesn't make sense at all?
IM-7240-1 is IMO a buggy BS rule:
https://www.sec.gov/rules/sro/box/2021/34-92755.pdf
and
https://www.sec.gov/rules/sro/box/2018/34-83163-ex5.pdf

 

No offence, but this validation was put in place to reject any complex order with erroneous price that could be place by guys like you. And your example shows that it's working.
I won't explain you why your example doesn't make sense because you seem to think that you are right and everything else is BS.

I was just trying to help here, and I guess I failed.

 

@rb7, either play fair and answer or risk to be blocked.

Of course the writers/proponents of that buggy rule will defend their BS till the bitter end...

Caught in the act!

 

Big boss:your response is in the running for the dumbest remark of the year on ET.