Preventing Duplicate Trade Fills Without Broker Lot IDs

# How do you handle order tracking (without unique Lot ID's)


# How do you handle order tracking (without unique Lot ID's)












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.

## Answer by Clebson Derivan (score 1)

https://quant.stackexchange.com/a/8609

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.

## Answer by Matt Wolf (score 1)

https://quant.stackexchange.com/a/8611

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.