I use multiple strategies, which is pretty common for algo trading.
And I need to precisely track each trade of my holdings and positions back to a strategy, and that is only possible if you provide the missing link, which is the tradeid from position and holding models. This missing link makes the application design complex, and unreliable,. In other words, the essential link to uniquely track a trade during its lifetime, by its tradeid, is missing in the API.
A position/holding linked to a trade by tradeid, and a tradeid linked to a strategy will be a very clear and straight forward, in designing an application that can use multiple strategies.
I had raised this issue a few months back, and this is making application unnecessarily complex, and you said that you were going to openup the backoffice API. I would like to emphasize, that this is a critical component in application design that's missing, what you can track on the day of the trade should still be traceable on the second and third day , and till the trade is on.
Hi @yousuf, The trading platform doesn't have this context. Portfolio to trade mapping is a part of backoffice. We will be able to provide this feature once the backoffice APIs are up. We do have plans of providing this in the future.
The most important entity when I buy something on amazon (as far as the API is concerned) is the orderid . I am able to track my order forever with it. All problems are tracked with it.
The most important thing in a trading API is the trade_id, and uniquely tracking a trade, that in essence is the purpose of the API. Everything else revolves around this.
A receipt without a receipt number is useless. In Zerodha's trading API, a trade cannot be tracked at all, nothing is there to track a trade (orderid, tradeid, positionid or holdingid) . How do you design an application ..??
The purpose of the API is to connect the client trading program with the server trading program, and the client has no way of uniquely identifying a trade. Does this make sense...??!!
I am writing to stress the importance of the missing link, as I feel this has nothing to do with the context that you are speaking about. The backoffice API is something different, to trade with API you absolutely need a tracking entity like a trade_id, this should have nothing to do with the backoffice or its API, this is what I am trying to stress again.
It is a very bad comparison. You can't compare e-commerce platform to a trading platform.
We do provide order id for every order and users can tag each order for their usage. We do provide trades of an order. You can use these to map portfolio at your end.
Nobody can do the mapping accurately. Our backoffice does the close to the accurate job. It involves many complex FIFO logics which are used to map portfolio to trades. There are way too many ad-hoc conditions involved like (corporate actions) bonus, split, reversal, reverse split. I have just mentioned corporate actions, there is more to it like auctions, settlement, way too many to write in a paragraph.
PS: Our team has been working on it from past two and half years to bring it close to accurate and you are comparing it to an Amazon order tracking
Whats the use of getting a primary key that works only on the first day? Can this be reliably used? And if you don't give us (the API users), something (like or similar to a primary key) to uniquely identify a trade, how do you ever keep track of a program that can do hundreds of trades with different strategies on various instruments? The trades are on average more than a day long.
Imagine this common scenerio : My application is long on an instrument from a month (trade1), and it again goes long last week (trade2) on the same instrument, and due to a bad spike today morning I manually get out of the trade2 ( you can understand, nothing can be truely and fully automated , supposing the program uses moving averages and it will wait for the next candle to exit , or a very bad news come up, so i have to exit manually).
As of now, I have to stop the application and manually enter all the exit details, and then run it again. otherwise, the application has two trades 'ON', and it will exit both, which is wrong. If the app queries and finds that the quantity in the holdings/positions has reduced , it will be unable to make out which trade has been closed, i.e which strategy's trade is running and which one will have to be checked for an input condition.
if I have the tradeid, (that works on nth day also), the app can query for the trade and know that the trade for a certain strategy has been exited, and the other long strategy's trade is running.
There are always conditions that I know I have to deal with manually, with any sort of automation. Uniquely identifying a trade, allows for an application to know which trade exactly has been closed, and which exact trades are manual.
My apologies for taking so much of your time, and being so elaborate and long .
I am not comparing e-commerce to trading , I am stressing the importance of a primary key in a table for us API users. Every computer program that keeps track of entities does so based on a key that uniquely identifies the entity being manipulated. And the whole mapping and logic gets blind without a tracking id that always works, not just on the first day.
Just imagine , giving everyone of your users the same id, you can very well still track and map each user using his i.p /password/ session combination, !!
an orderid that works, for the entire life of the trade, or a tradeid that works for the entire life of the trade,
Dont you think this is a primary requirement for designing a trading app?
Thanks a lot for your time.! and I would like to add the API is really simple and sweet to work with and you fellows no doubt are doing a great job..!! And thats the reason for my interest, and this post going this long ..!!
The trading platform doesn't have this context.
Portfolio to trade mapping is a part of backoffice. We will be able to provide this feature once the backoffice APIs are up. We do have plans of providing this in the future.
The most important entity when I buy something on amazon (as far as the API is concerned) is the orderid . I am able to track my order forever with it. All problems are tracked with it.
The most important thing in a trading API is the trade_id, and uniquely tracking a trade, that in essence is the purpose of the API. Everything else revolves around this.
A receipt without a receipt number is useless. In Zerodha's trading API, a trade cannot be tracked at all,
nothing is there to track a trade (orderid, tradeid, positionid or holdingid) . How do you design an application ..??
The purpose of the API is to connect the client trading program with the server trading program, and the client has no way of uniquely identifying a trade. Does this make sense...??!!
I am writing to stress the importance of the missing link, as I feel this has nothing to do with the context that you are speaking about. The backoffice API is something different, to trade with API you absolutely need a tracking entity like a trade_id, this should have nothing to do with the backoffice or its API, this is what I am trying to stress again.
Thanks
Yousuf.
We do provide order id for every order and users can tag each order for their usage. We do provide trades of an order. You can use these to map portfolio at your end.
Nobody can do the mapping accurately. Our backoffice does the close to the accurate job. It involves many complex FIFO logics which are used to map portfolio to trades. There are way too many ad-hoc conditions involved like (corporate actions) bonus, split, reversal, reverse split. I have just mentioned corporate actions, there is more to it like auctions, settlement, way too many to write in a paragraph.
PS: Our team has been working on it from past two and half years to bring it close to accurate and you are comparing it to an Amazon order tracking
Thanks for the reply.
Can I query today, using an orderid I got yesterday (for an order filled yesterday), and get the trades filled by it?
Regards
Whats the use of getting a primary key that works only on the first day? Can this be reliably used?
And if you don't give us (the API users), something (like or similar to a primary key) to uniquely identify a trade, how do you ever keep track of a program that can do hundreds of trades with different strategies on various instruments? The trades are on average more than a day long.
Imagine this common scenerio : My application is long on an instrument from a month (trade1), and it again goes long last week (trade2) on the same instrument, and due to a bad spike today morning I manually get out of the trade2 ( you can understand, nothing can be truely and fully automated , supposing the program uses moving averages and it will wait for the next candle to exit , or a very bad news come up, so i have to exit manually).
As of now, I have to stop the application and manually enter all the exit details, and then run it again.
otherwise, the application has two trades 'ON', and it will exit both, which is wrong. If the app queries and finds that the quantity in the holdings/positions has reduced , it will be unable to make out which trade has been closed, i.e which strategy's trade is running and which one will have to be checked for an input condition.
if I have the tradeid, (that works on nth day also), the app can query for the trade and know that the trade for a certain strategy has been exited, and the other long strategy's trade is running.
There are always conditions that I know I have to deal with manually, with any sort of automation. Uniquely identifying a trade, allows for an application to know which trade exactly has been closed, and which exact trades are manual.
My apologies for taking so much of your time, and being so elaborate and long .
I am not comparing e-commerce to trading , I am stressing the importance of a primary key in a table for us API users. Every computer program that keeps track of entities does so based on a key that uniquely identifies the entity being manipulated. And the whole mapping and logic gets blind without a tracking id that always works, not just on the first day.
Just imagine , giving everyone of your users the same id, you can very well still track and map each user using his i.p /password/ session combination, !!
an orderid that works, for the entire life of the trade,
or a tradeid that works for the entire life of the trade,
Dont you think this is a primary requirement for designing a trading app?
Thanks a lot for your time.! and I would like to add the API is really simple and sweet to work with and you fellows no doubt are doing a great job..!! And thats the reason for my interest, and this post going this long ..!!