2
$\begingroup$

Hypothetical Trade:

I buy 10,000 shares of ASTC using a broker API.

The order is filled in 4 similar lots;

2500 shares at 0.80
2500 shares at 0.80
2500 shares at 0.77
2500 shares at 0.77

The easiest way to record these lot fills is if the broker issues a UNIQUE "Lot ID" like this:

2500 shares at 0.80 --- LOT ID# 3484HGK
2500 shares at 0.80 --- LOT ID# DFD38HF
2500 shares at 0.77 --- LOT ID# JJVKD89
2500 shares at 0.77 --- LOT ID# FJF9D93

THE PROBLEM:

Unfortunately, the broker does not issue LOT ID#'s (yet). A computer program will see the lot fills many times.

WHAT LOGIC DO I USE TO PREVENT THE PROGRAM FROM RECORDING EACH LOT FILL MORE THAN ONCE?

Suggestion 1: I can make a hash based on the attributes of the LOT. That may work, however, if everything matches (timestamp, number of shares, symbol, price) I will get duplicate hashes.

Suggestion 2: Use the alert notifications. I am not sure the notifications are available from the API.

I would like to know how others have handled this tracking issue.

Improve this question
$\endgroup$
6
  • 1
    $\begingroup$ How could a fill be counted more than once? Every time you see a fill, that should be a new unique trade. $\endgroup$
    – chrisaycock
    Jul 31, 2013 at 16:38
  • 1
    $\begingroup$ I like suggestion 1 if the only info you get is what you provided. Salting the hash will take care of duplicate hashes(if possible) $\endgroup$
    – jeff m
    Jul 31, 2013 at 16:43
  • $\begingroup$ If you are having this problem, you must not be using everything the broker is offering you, I can't imagine an API that doesn't let you uniquely identify specific fills, and hopefully even which order they come from (though that might not be possible). $\endgroup$
    – experquisite
    Jul 31, 2013 at 21:31
  • $\begingroup$ experquisite: I got the following message from the tech support of the broker (after months of communication): "Lot ID numbers are not returned within the responses for our current APIS. A future update to our APIs will include specific identifiers for each lot. We do not have details at this moment as to when the updates will occur, but the documentation and information through our API pages will be updated accordingly." $\endgroup$
    – Autowealth
    Jul 31, 2013 at 22:03
  • 2
    $\begingroup$ Is this really relevant? Sounds like you need a new broker without a broken API. There is no real question here. $\endgroup$
    – Louis Marascio
    Jul 31, 2013 at 22:40

2 Answers 2

Reset to default
1
$\begingroup$

you forgot to mention what broker or api you are using. AFAIK every broker/exchange provides a execution id, wich is unique for every trade on the trade session, with the execution id and your order id you can group the trades for the order sent. You could check the execution report of the FIX Protocol its based on the industry standard and the majority of brokers use it to deal with the exchanges/ecn.

Improve this answer
$\endgroup$
1
  • $\begingroup$ I am using the Etrade broker and API. One problem is that the documentation does not seem to cover lots. Moreover, while they have a sandbox, it does not really return all of the information that is returned during live trading. Etrade does NOT use the Fix Protocol. Coincidently, I find that many of the brokerages that I would like to use do not support FIX on their API. $\endgroup$
    – Autowealth
    Jul 31, 2013 at 22:08
1
$\begingroup$

I think you are focusing on lots when you should focus on having the API return the original orderID, that is what really matters, not LotIDs (though every API of average quality should generate a unique ID for each individual fill as well).

Chrisaycock is right in saying that each fill you receive should automatically be unique. So you are by definition not double counting even if you are not able to uniquely allocate each fill to the original order.

However, you need to find a way to either a) tag your original order you send to your broker with your own unique orderID or b) if the API permits get the assigned original orderID from the order you submitted so you can later on match the fills that are tagged with either your original orderID or the one of the broker.

To summarize, you should never get double counted fills from your broker. If that is the case you should definitely dump that API or change brokers. A fill you receive should be a unique fill, never anything else.

Improve this answer
$\endgroup$

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge that you have read and understand our privacy policy and code of conduct.

Not the answer you're looking for? Browse other questions tagged or ask your own question.