Dissecting the Nest Plus Auto Trading API

Re: 3. A dry run ... [2]

No, I do not call any function to get the Order ID, order ID is sent to me and so is exchange ID. So, status is notified to me. If I need to check for status from my end, I can initiate another call and it will be sent to me.

Re: 3. A dry run ... [2]

Not clear ... the "sent to me" part.

After you place an order, is the order ID / exchange ID / status one of the pass by reference parameters / return value. That cannot be possible for asynchronous.

Or in the Sharekhan API, do you have a callback in place?

Re: 3. A dry run ... [2]

No. I would'nt label it as "callback". It is more like 2-way messaging. I send X. I get reply as Y. Of course, I've had to implement a listener on my end that continuously polls a computer port for their reply and the "listener" internally has a callback function whenever it finds something worthwhile.

Re: 3. A dry run ... [2]

Sound good.

5. SetObjectName

The object created in the first step needs a name. The name could be anything suitable; it need not be your user ID as many examples tend to use. Since CreateObject is an operating system action, this is the point at which Plus checks if you are subscribed to the Trading Plugin. If not, a window will come up with

[NestPlus_login_name] is not enabled on API

Beyond this, SetObjectName has very little functionality. It is used in the title of the API Generated Orders window where it is qualified with the time (which makes it a beast to handle programmatically). It also shows up in the Remarks columns of the Orders Book once an order is placed. If using CreateStaticObject, setting the object name on subsequent occassions has no effect -- the first name is retained. Plus does not seem to care if the same name is assigned to multiple objects.

The image below shows the Orders Book after a few orders were placed, with 'DryRun' in the Remarks column. Notice also that 1 buy order was rejected with reason as an invalid tick size; though it was correctly placed at 102.35

The order appears to have been received at exchange's end with tick size as 102.34 (as per the pic)

That is correct, but the question is why since it was placed at 102.35 ? (and reflects as such in the Generated Orders window; see the last order in the image)



I suspect the truncation is between Ami and the Nest API. For example, if the order had been placed at 102.351, it would probably have been accepted at 102.35. Also likely that it has to do with Amibroker using single-precision in many situations (~7 significant figures), and the Nest API using double-precision. Unless some peculiar floor behavior is happening somewhere, it should not have happened with this value.

Will be looking deeper into this.

Why indeed!!!?
That ought to be food for some serious thought for people looking at auto trading utopia.

Amibroker uses double precision as default unless otherwise specified.

Most likely another 'bug under the omnesys rug'.

P.S - The 100.15 order is also showing as 'CNC' which was rejected as 'NRML', unless that was order no.1! Not able to understand why two separate orders have same no? This would pose a problem for order query.

They say: pay attention to the P.S. as that it where the important stuff is.

While not mentioned earlier, there were two dry runs with a total of 5 orders placed. Three of these were a buy at 100.15, and one of these 3 was a NRML, which was befittingly rejected.

Was just checking out what happens if duplicate order numbers occur. It seems that Nest does not monitor this possibility, nor could I locate any field in the Orders Book that displays them. So, as you mention, using duplicate order numbers is cutting off the branch that you'll need to sit on.

Ran a quick test today to check how frequent the 'tick size' issue could be. Sending orders in price steps of 0.05 resulted in 4 out of 9 getting rejected.



However, adding a delta of 0.001 to price resulted in all orders getting accepted. Still need to make a corresponding check using an alternative to Ami AFLs.