Welcome to NexusFi: the best trading community on the planet, with over 150,000 members Sign Up Now for Free
Genuine reviews from real traders, not fake reviews from stealth vendors
Quality education from leading professional traders
We are a friendly, helpful, and positive community
We do not tolerate rude behavior, trolling, or vendors advertising in posts
We are here to help, just let us know what you need
You'll need to register in order to view the content of the threads and start contributing to our community. It's free for basic access, or support us by becoming an Elite Member -- see if you qualify for a discount below.
-- Big Mike, Site Administrator
(If you already have an account, login at the top of the page)
Ninja Trader Custom Order Book - 1LDom - Source Code
Never tried it myself but I would start by recording the sequence of the refresh and then analysing it for a consistent timing pattern. It would be much more complex I believe than a simple formulae. Most likely you would need to look into pattern analysis or scanning of some type. Once you have a set of criteria you leave the machine to do the work and watch the days play. The problems I foresee is different people will be using different refresh algo's and you have no way of knowing who's who in order to try and identify any consistent patterns.
Secondly the refresh rate patterns. If it was me anyway and I was looking to chuck a couple of thousand into the market I would be dam sure to scramble the order placement sequence in terms of time. You are essentially getting into algo wars here. I haven't delved too deeply into this myself but I would be interested to hear other comments if anyone has anything to share.
Maybe one issue is that Iceberg orders will usually manifest themselves on what most traders view as the wrong side of the bid/ask. (i.e. if there is an Iceberg seller, orders will continually hit the Ask and the DOM will show little size change as the Iceberg absorbs the trades.)
T&S window shows lots of trades at the Ask indicating buying pressure to make the price rise.
But each time the orders hit the Ask, the size is refreshed and the price does not move.
Most traders would view the large buy side pressure as a reason to buy that level.
But the Iceberg trader is refreshing the orders and not allowing the price to rise.
The result is seen when the buyers are exhausted and the price moves down.
At that point the Iceberg seller will start hitting the Bid and pushing the price further down.
The end result is the buyers into the Iceberg have their stops hit and further selling (stop outs) push even lower.
Rejoice in the Thunderstorms of Life . . .
Knowing it's not about Clouds or Wind. . .
But Learning to Dance in the Rain ! ! !
I was lying in bed thinking about this IceBerg thing again last night, call me crazy but something else occurred to me. I was thinking through the problem of how I would go about it algorithmically. So another couple of issues came to mind which I hadn't thought of but first lets lay out the basics.
So if we are looking for refresh rate patterns right, we need to record each and every change of bid or ask and then time stamp each and every one of them. So we would end up with a sequence of say.
258 -> 300 -> 250 -> 385 -> 290 -> 270 : Just an example so in this case we have trades going through or orders being pulled and then we have the bid offer being refreshed. So we would want to filter only the adds and forget the others for now.
So:
(258 - 300 ) 42 (300 - 250) no add (250 - 385) 135 (385 - 290) no add (290 - 270) no add
Right essentially we have had the bid/offer charged up twice. 42 added at one point and 135 added at another point. So lets make the example a little more complex, lets say we have a string of quick recharges. Typical of ES. Ignore trades and pulls. Just straight as in above but only a long line of adds/refreshes.
[10,15,20,10,18,20,30,35,10]
So alone they mean nothing. However if we time stamp each and everyone down to the millisecond and then calculate the time interval. We may have something to work with.
So in above timing pattern my thought would be that robots or algos being mechanical they would typically generate some sort of consistent timing pattern. One could say potentially we have a pattern match on the last 6 refreshes.
Granted this is extremely basic. I'm just sorta thinking out loud here with some initial thoughts. For some reason this seems to peak my interest even though I know I should be leaving it alone.. lol
I guess the above being as simple as it is, in a more complex environment with algos using less consistent patterns we would need to store all bid ask data coming in and then run some sort of pattern routines on the information to perhaps show up potential non-human patterns that work with large quantity. Once having filtered certain patterns we would configure our algo to scan live bid/asks for these similar patterns which we have a record of.
One challenge I see though is that as the exchange doesn't time stamp bid offers, we would be left to our own devices in terms of trying to calculate the time stamp and the issue of network latency seems to introduce an element of randomness that may be very difficult to filter out. I'm not an expert in this so wouldn't know how to approach it.
There is a chap who's thread I have followed for a while called @artemiso , I suspect this topic may arouse his interest and would love to hear if he has anything to say on it.
@artemiso if you see this we are basically just throwing around some ideas about Icebergs in the order book and detection mechanisms or approaches to narrow it down, track other players. Would be interested to hear your thoughts if you have some time?
Now that I laid that all out I can't remember what the other issue was that I thought of 1. was network latency for recording accurate timing. 2. has gone down a black hole. When I think of it again will add it.
I don't think there's any way you can reconstruct an 'iceberg' that is created by the institutional bot - it can be randomized over a price range, a time frame, and sizes.
Orders placed as Icebergs at the CME, however, seem more detectable :
Hidden Quantity
A Hidden Quantity order—also called
MaxShow or Iceberg—displays only a
portion of the order to the marketplace.
When the displayed quantity has been
filled, another portion equal to the
displaced quantity is then displayed as a
new order at the bottom of the book.
I'm not sure what they mean by 'displaced quantity', and if I pursue it I think I'd contact CME for more detail and clarification. But I'm also not sure if it's worth pursuing this sort of extra precision, rather than just looking at the overall additions.
In general, my trading tends to improve in inverse proportion to the time I spend programming and tinkering.
Agree. Only Mondays and Fridays are now programming/research/also half-size trading days. Tuesdays, Wednesdays and Thursdays I really do try to earn my keep, with only left-field ideas onto scribble pad or hot bug-fixes in C# allowed.
I'll try not to go on record for saying something that I'm not an expert on (CME). On Globex, I think it is more difficult to deal with second generation implied quotes. For iceberg orders, you can detect them to about 90+% accuracy and estimate their sizes down to +/-5% in realtime (it may seem strange that it's more difficult to classify trade initiator than predict iceberg size, but there's mathematical intuition for this because the constraints here are well-defined). So detection is not the interesting part - the challenge depends on what you would do even if you can see all hidden orders in the order book.
this is not a critique, and I know it's a fine line. and the most important it's your forum with your rules. I would just like to point out, that everything always depends. which of course is just human nature.
the following post shows a vendor posting a video with his indicators. I don't have a problem with that at all. this vendor, as I believe, is well respected here. but someone else doing the same thing might have ended up in big trouble.
It comes down to context and intent based on my (and others) point of view. I know your feelings already based on your actions. No need to derail this thread further.
I need to do some reading up on "second generation implied quotes", no idea what that is.
I agree that having deciphered where various Icebergs are in the book and potential size is not necessarily particularly helpful since who is to say what is the predictive capacity.
The reason it piqued my interest was the idea of potentially being able to identify a subsection of players in the book by identifying what could potentially be signatures or identifiable patterns that there algo's use to refresh there orders. Not to say this would in anyway be possible but understanding the mechanisms involved, the approach and the challenges one would face in trying to accomplish such a task I think would be a general improvement of ones own knowledge on the subject, or at least mine anyway.
I need to go do a bit more Iceberg research myself to understand exactly how those orders are working. I've seen Iceberg options on my CQG platform. I've always assumed that it's an order type that like Ninja's local orders does not sit on the exchange itself but CQG basically holds the info and then fires them in with an algo. I also thought that other firms would do similar and big players would all have there own algos for dropping orders. So potentially there is few different types of algo's for Icebergs but again I am just thinking out aloud. I need to go and do some reading really.
Appreciate you coming to share your thoughts here @artemiso.
