Hi, Tried to place a CM margin cover order for CO SELL SYNDIBANK-EQ today at 10:22am, at LTP 91.6, quantity 1518, SLP 94. The co_upper is 3.5 (as per today's margin returned by kite api). So the upper limit is 94.806. The API call was successful & it fired the order to exchange, but it got rejected there, with error msg 'trigger price should be 3.5% for syndibank-eq'.
It is my understanding that 94 is within the SL trigger range and should go through fine, since any value between 3 (co_lower) and 3.5 (co_upper) should work. Not sure why the order is failing.
Similar failures seen for KTKBANK and BANKINDIA as well.
Hi @ramatius, Trigger price range changes real time according to movement of LTP. The order for SYNDIBANK-EQ of quantity 1518 is completed and counter order is also complete.
For another order at around 13:00 for the same instrument, at that moment price was around 90.35 and based on that trigger price can be max up to 93.50 and trigger price sent was 94.35. Hence it was rejected. This is the case for other rejected orders today.
Yes, we tried some price ranges to test the system behavior. Ok so the logic that the SLP should fall between co_lower and co_upper holds good, right?
If the price movement is high, it is almost impossible to get the SL number right - by the time the call is fired, the price would've moved far enough to invalidate the order.
It would be great if the API can accept a relative % instead of a fixed SL figure. This will make the system more robust and API calls won't fail. Please consider implementing this.
Hi @ramatius, I am afraid we can't make changes to that logic. It's not a part of Kite Connect. It depends on our RMS and OMS. A feasible solution would be to fetch trigger range just before placing the order and avoid giving trigger price equal to maximum possible value.
@sujith Cover Order is the most attractive option due to high leverage and volatility. If CO can't be reliably used by algo, then it greatly reduces the usability of system across the board. The SL ranges for MCX & CDS are wide enough, but not for CM.
Large classes of profitable algorithms will go out of scope if CO is not robust enough for CM.
Hi @ramatius, You can check out this example. Another solution is to calculate it on your end, it is easy Let's say co_upper is 3.5% (value retrieved from API) then trigger upper limit = LTP + (LTP * 3.5/100) API will return the same value. This might also save some bandwidth for you as well.
I would suggest giving value little far than the minimum value and maximum value and make sure time gap between fetching trigger range and placing an order is minimum.
Trigger price range changes real time according to movement of LTP.
The order for SYNDIBANK-EQ of quantity 1518 is completed and counter order is also complete.
For another order at around 13:00 for the same instrument, at that moment price was around 90.35 and based on that trigger price can be max up to 93.50 and trigger price sent was 94.35. Hence it was rejected.
This is the case for other rejected orders today.
If the price movement is high, it is almost impossible to get the SL number right - by the time the call is fired, the price would've moved far enough to invalidate the order.
It would be great if the API can accept a relative % instead of a fixed SL figure. This will make the system more robust and API calls won't fail. Please consider implementing this.
I am afraid we can't make changes to that logic. It's not a part of Kite Connect. It depends on our RMS and OMS.
A feasible solution would be to fetch trigger range just before placing the order and avoid giving trigger price equal to maximum possible value.
Large classes of profitable algorithms will go out of scope if CO is not robust enough for CM.
Tagging @nithin for further thoughts on this.
You can check out this example.
Another solution is to calculate it on your end, it is easy
Let's say co_upper is 3.5% (value retrieved from API) then
trigger upper limit = LTP + (LTP * 3.5/100)
API will return the same value. This might also save some bandwidth for you as well.