SmartQuant Discussion

I was wondering if it is possible to fetch what type of order has gone through. TT outputs type of order (whether it was Buy or Sell) but SmartQuant seems not recognizing it.

There always is a buyer and a seller in a trade, so I guess there can't be "buy" or "sell" trade.

Regards,
Anton

Of course there is always a buyer and a seller, but one of them is showing the offer (or bid) and the other one takes the offer (or bid) hitting the market. TT on its time and sales indicates which of them was market buy and which was market sell. That would be great if you could include it in SmartQuant...
Thanks

Hi,

Which TT plugin do you mean? TT API or TT FIX?

Regards,
Alex

_________________
SmartQuant Development Team

I am using TT API. Is there any difference? And by a difference I mean class implementation...

Guys,
any news about this? It's still a foundamental aspect to determinw in which direction the market is moving.

Regards

I guess you don't mean an order, you mean a trade record (OQ Trade object), right?

Anton,
TT has a box called Time & Sales, which in the API returns the object Trade. That object contains also the "direction" of the trade, which can either be buy or sell. As a trader I can tell you that is very usefull to have a clear view regards the market, if people are hitting the bid or lifting the offer. I've seen an implementation on TT API developer's forum, and I think it shouldn't be too complicated to have also this property in OQ.

Regards

Yes, I know, but the problem is that the trade object in the underlying framework doesn/t have this field and to add it we need to update the entire data propagation / storage chain.

We are currently working on a new version of the framework. Perhaps we should include more information into the trade (time and sales) record. On the other hand it's also important to keep this object as lightweighted as possible. This affects memory requirements, backtesting speeds, latency, etc. If you look at the raw TAQ (NYSE) time and sales data, you will see that on e trade record has tens of different fields apart from price and size. Should we reserve space for all of them?

Cheers,
Anton

Anton,
speed is a very important characteristic of OQ, and it shouldn't be changed. Anyway you can simply leave the Trade category as it is, while creating a new richer "Trade" category, called ie. Time&Sales, SuperTrade or whatever, which can handle more datas, like you said for the NYSE datas. In this way you can preserve speed, but giving the opportunity for people less relaiant on speed a way to trade that kind of datas.

Kind Regards

/// <summary>
/// This function is called when an instrument udpate
/// occurs, however, this data is not coalesced.
///
/// NOTE: Fired when DeliverAllPriceUpdates is enabled.
/// </summary>
/// <param name="pNotify">TTInstrNotify object</param>
private void m_TTInstrNotify_OnPriceListUpdate(XTAPI.TTInstrNotify pNotify)
{
try
{
if (pNotify != null)
{
//Set variables
string sMsg = null;
string direction = null;
double ltp = 0.0f;
int ltq = 0;

foreach (XTAPI.ITTPriceUpdate priceUpdate in pNotify.PriceList)
{

//Loop through PriceEntries in PriceUpdate
foreach (XTAPI.ITTPriceEntry priceEntry in priceUpdate)
{
switch (priceEntry.PriceID)
{
//Calculate Last Traded Price
case XTAPI.enumPriceID.ttLastTradedPrice:
ltp = priceEntry.toDouble();
break;
//Calculate Last Traded Quantity
case XTAPI.enumPriceID.ttLastTradedQty:
ltq = (int)priceEntry.toDouble();
break;
//Calculate Hit or Take
case XTAPI.enumPriceID.ttHitTake:

if (priceEntry.toDouble() == Convert.ToDouble(XTAPI.enumTradeIndicator.TRADE_INDICATOR_HIT))
{
direction = "Hit"; //Sell
}
else if (priceEntry.toDouble() == Convert.ToDouble(XTAPI.enumTradeIndicator.TRADE_INDICATOR_TAKE))
{
direction = "Take"; //Buy
}
else if (priceEntry.toDouble() == Convert.ToDouble(XTAPI.enumTradeIndicator.TRADE_INDICATOR_UNKNOWN))
{
direction = "Indeterminate"; //Indeterminate
}
break;
}
}

//Get timestamp of PriceUpdate
string timestamp = priceUpdate.TimeStamp.Substring(0,8);


//Write message
sMsg = m_Cnt + "," + timestamp + "," + priceUpdate.Instrument.Exchange + "," + priceUpdate.Instrument.Product + "," + priceUpdate.Instrument.get_Get("Expiry") + "," + direction + "," + ltp + "," + ltq;

//Add sMsg to ListBox
lboPriceList.Items.Add(sMsg);
//Increase count
m_Cnt = m_Cnt + 1;
}
}
}
catch (Exception ex)
{
Console.WriteLine(ex.Message + "," + ex.StackTrace);
}
}

This is the TT Code, as you can see is just a comparison between quotes side and where the trade hit the book. It shouldn't be so difficult to implement. Anyway I can write a DLL to add this feature if anyone is interested!

Regards

Yes, it's easy to get. The problem is that we have no place to put this information in ...

Don't worry I've got an idea. I'm writing a DLL with an integrated small database (OQ Stile!) to store those informations. Thanks for the suggestion, I will eventually post my results if anyone is interested!

Regards

If you write a custom plugin for TT API (we can give you the code for the built-in plugin, but I doubt it would help since our plugin is developed for the underlying framework, i.e. it's not derived from OQ UserProvider), you can probably use a sign at Trade.Price / Size to send trade direction alone with trade data... Negative size is take, positive is hit... Just an idea...

Good suggestion Anton!! Well, simply on your plugin, once I have EmitTrade() trigger on a trade event I can add this code as part of the process, invoking another event, ie. OnErrorEvent with a custom error ID to store the trade direction! Or is that possible to add an event to OQ? In that case it would be much simpler!

Btw do you think is possible to add this feature also for the IB plugin? As I don't know too well IB API's I would like to know from your previous experiences.

Regards