@EUH6 order fill issue - another C2 software bug?

I have a GTC buy order from last Friday for 2 @EUH6 at price of 1.1852, and it is still pending there without being filled - which it should have been 12 hours ago when @EUH6 dropped to as low as 1.1835. Is this a C2 software bug? Could C2 please give the confirmation as soon as possible so that I can move on?

Last time things like this happened was on 2/19/06 (Sunday) night when the future market (including @EUH6) was open but C2 somehow was not functioning (because of the long weekend?). That night @EUH6 rebounded to 1.1980+. I entered sell order there at 1.1980+. At some point the next day, C2 started to function again but that sell order (@1.1980+) still not getting filled until several hours later when the confirmation (that the sell order was filled) finally showed up. Very strange.

Problem like this is very annoying, because for us we will have no idea what to do without knowing whether or when the order fill confirmation will show up.

There goes the problem again: these two BTO limit orders for EUH6 were set on 3/6/2006 afternoon after market close (i.e. more than 8 hours from now already). Two hours ago EUH6 dropped to as low as 1.1948 but C2 only filled the 1.1963 one (1 contract) not the 1.1955 one (for 2 contract).

So what’s the deal here? Is C2 going to fill the 1.1955 order or not (which it should)?


Emailed, trade filled @1.1963 (3/7/06 0:00) 3/6/2006 Buy to open 1 @EUH6 @ limit 1.1963 GTC Reverse

Emailed, trade pending 3/6/2006 Buy to open 2 @EUH6 @ limit 1.1955 GTC Cancel XRplc

EUH6 went higher to 1.198 and now come down again to 1.195+, and now I see C2 has filled the 1.1955 buy order. Now the question (still) is: why C2 didn’t filled the 1.1955 order 3 hours ago when it should?


This morning, after reading your post, I looked at the @EU price chart. Sure enough, you were right; C2 should have filled your order at around midnight, when @EU dropped down below 1.1955.

I was curious why C2 didn’t fill you at that time. So I checked the server logs. What I found was very interesting: at the time when you should have been filled, the quote feed didn’t show the price reaching that level. At the risk of being tedious, let me take you behind the scenes, into the bowels of Collective2’s software.

Here is the audit log from last night. This is the data our quote feed gave us about @EU, at around midnight (O,H,L,C format).

3/7/2006 00:00:00 AM,1.1960,1.1963,1.1958,1.1958,6077

3/7/2006 00:01:00 AM,1.1959,1.1965,1.1957,1.1965,6271

3/7/2006 00:02:00 AM,1.1963,1.1963,1.1960,1.1962,6363

3/7/2006 00:03:00 AM,1.1963,1.1965,1.1963,1.1963,6454

3/7/2006 00:04:00 AM,1.1963,1.1966,1.1963,1.1963,6558

3/7/2006 00:05:00 AM,1.1963,1.1966,1.1963,1.1964,6773

3/7/2006 00:06:00 AM,1.1964,1.1966,1.1963,1.1966,6909

3/7/2006 00:07:00 AM,1.1965,1.1967,1.1963,1.1963,6924

3/7/2006 00:08:00 AM,1.1965,1.1965,1.1962,1.1964,6942

3/7/2006 00:09:00 AM,1.1963,1.1963,1.1957,1.1957,6986

3/7/2006 00:10:00 AM,1.1962,1.1964,1.1962,1.1964,7115

3/7/2006 00:11:00 AM,1.1964,1.1965,1.1964,1.1964,7120

Notice the low of 1.1957 at appoximately 12:01 am. A low of 1.1957 would not have triggered your Buy Limit 1.1955.

OK. Now, let’s look at the prices returned to us this morning, for the same time period, and the same symbol:

3/6/2006 11:30:00 PM 1.1997 1.2001 1.1996 1.1996 3811

3/6/2006 11:45:00 PM 1.1996 1.1999 1.1990 1.1993 3957

3/7/2006 0:00:00 AM 1.1992 1.1992 1.1948 1.1958 6077

3/7/2006 0:15:00 AM 1.1959 1.1967 1.1957 1.1964 7150

3/7/2006 0:30:00 AM 1.1965 1.1969 1.1964 1.1968 7366

Different bar lengths, but the main point is that the low is now 1.1948. How the heck did that happen?

The reason I am giving you this long, involved explanation is to show that C2 is a very complex simulation, and a lot can go wrong. Only some of it is our fault. There are many different software layers at work, attempting to check and re-check decisions that are made. Often we can catch bad ticks. Sometimes we can’t. Remember that C2 is a simulation. Since no actual trades take place, we need to simulate trading, based on price data. We are at the mercy of our data vendors and (ultimately) the exchanges. If they give us a bad tick or two, results will be affected, and – as in this case – fills will be delayed.

So, I apologize for the problem. It is atypical. If it does happen, here’s what to do: Report it to me and I will look into it. C2 processes many thousands of orders each day. The software gets most of them right. There are always a few exceptions, and I will work hard to resolve any mistakes.

P.S. There’s a new “bad fill” reporting feature that anyone can use to report a bad fill (or missing fill) for any trading system. Just click the “Show Customer Service” link on the trading system page.


Thanks for the explanation. The quote problem C2 seemed to have encountered in this case is very well understood.

The main problem that bothers us is the “delayed confirmation” problem that I mentioned in my original post of this thread. Those are the strange cases where the confirmation for the “supposed-to-be-filled” trade never showed up until some 24 hours later when it suddenly showed up saying the trade was filled 24 hours ago. I have experienced at least twice such cases on C2. I couldn’t imagine what could be the cause for that but such kind of “delayed confirmation” problem is indeed very annoying as when things like this happens we just have no idea what to do other than waiting.

I had a similar problem last Friday. I had a LFH6 position open which I wanted to close; I placed a market order at 3:45pm and for some unknown reason it was closed at the 3:00pm price. Additionally, the order ticket had 3:05pm on it! All in all this reduced my notional equity by £55K!

I have reported the error but haven’t received a reply as yet.