How about threaten to send these hft abusers to hell on earth aka france?
You are using an out of date browser. It may not display this or other websites correctly.
You should upgrade or use an alternative browser.
You should upgrade or use an alternative browser.
Minimum time before Order Cancel
- Thread starter PocketChange
- Start date
I just reread Nanex's proposal...
It's sweet and simple and would do the job very well... Just implementing a new quote condition = "Immediate" and requiring the original exchange order time stamps to be preserved and passed through without altercation.
Orders Marked as immediate can not set NBBO and may be cancelled instantly and easily filtered.. non immediate quotes may set NBBO and may be cancelled after 1 second.
The time stamps will identify delayed /stale quotes and orders.
Any down side? Devil's advocate anyone?
It's sweet and simple and would do the job very well... Just implementing a new quote condition = "Immediate" and requiring the original exchange order time stamps to be preserved and passed through without altercation.
Orders Marked as immediate can not set NBBO and may be cancelled instantly and easily filtered.. non immediate quotes may set NBBO and may be cancelled after 1 second.
The time stamps will identify delayed /stale quotes and orders.
Any down side? Devil's advocate anyone?
Which timestamp?
There is a timestamp when an order hits the edge of the exchange's infrastructure.
There is a timestamp when the order hits the matching engine.
There is a timestamp when the order exits the matching engine (ie, book update or trade event). The differential between the this timestamp and the above timestamp is not a constant, and will be a function of both message traffic quantity and where in the book the order lands.
There is a timestamp when the golden market data feed for this event is actually generated.
There is a timestamp when the golden feed hits the actual distribution point.
How are you going to synchronize everybody's computers so the timestamp has meaning in the absolute sense? At these timescales, you're not, because it's impossible without massive expense. So now the timestamp is a relative measure between the receiver and the sender. Which means software changes on the receiver side to continuously recalibrate, because non-colo connection speed/throughput are filled with all kinds of variances when talking about these kinds of timescales.
That sure doesn't sound like fun.
Are your Java-based systems deterministic enough that you can count on milisecond-scale repetition? Under a variety of market conditions? Very few are.
But this all begs the question of what problem is being tackled. Because on anything resembling a liquid stock/future, it's easy to get consistent fills if you're simply willing to accept one tick off the BBO. So for "investors", this is all a total non-issue anyway - which means we're really talking about Spy vs Spy - ie, there are no White Hats.
If the concern is having too many quotes of dubious value for the general trading audience on the main feed, there is a simpler solution. Give the ultra-fast folks a unique Participant ID for their fast algos (eg, add "FAST" to their root PID, or etc), and filter the golden market data feed to strip out any update with those identifiers for recipients who place no value on those quotes. Customers can decide for themselves which feed makes the most sense.
There is a timestamp when an order hits the edge of the exchange's infrastructure.
There is a timestamp when the order hits the matching engine.
There is a timestamp when the order exits the matching engine (ie, book update or trade event). The differential between the this timestamp and the above timestamp is not a constant, and will be a function of both message traffic quantity and where in the book the order lands.
There is a timestamp when the golden market data feed for this event is actually generated.
There is a timestamp when the golden feed hits the actual distribution point.
How are you going to synchronize everybody's computers so the timestamp has meaning in the absolute sense? At these timescales, you're not, because it's impossible without massive expense. So now the timestamp is a relative measure between the receiver and the sender. Which means software changes on the receiver side to continuously recalibrate, because non-colo connection speed/throughput are filled with all kinds of variances when talking about these kinds of timescales.
That sure doesn't sound like fun.
Are your Java-based systems deterministic enough that you can count on milisecond-scale repetition? Under a variety of market conditions? Very few are.
But this all begs the question of what problem is being tackled. Because on anything resembling a liquid stock/future, it's easy to get consistent fills if you're simply willing to accept one tick off the BBO. So for "investors", this is all a total non-issue anyway - which means we're really talking about Spy vs Spy - ie, there are no White Hats.
If the concern is having too many quotes of dubious value for the general trading audience on the main feed, there is a simpler solution. Give the ultra-fast folks a unique Participant ID for their fast algos (eg, add "FAST" to their root PID, or etc), and filter the golden market data feed to strip out any update with those identifiers for recipients who place no value on those quotes. Customers can decide for themselves which feed makes the most sense.
NTP can be used to sync time with high precision ie. meinberg.de http://www.meinberg.de/english/sw/ntp.htm
I don't think the two changes proposed are an onerous load on any party. It should provide transparency on price discovery and allow all participants to make informed decisions based on higher integrity market data. The way timestamps are managed now is nothing more than a high tech 3 card monty.
The Timestamp issue as addressed in the Nanex proposal:
"Require the time stamp field in all quote messages to be set to the time the quote was created at each exchange, instead of when it is transmitted by the network processors (SIP). This will allow all downstream users to accurately compute the age of each quote."
"Everyone will be able to compute the exact age or delay in every quote (chalk it up to modern computing, trust us on this), and therefore determine if there is enough time to execute against it. "
2. "Currently, every quote message has a timestamp field which is filled (replaced) by CQS when the quote is ready for transmission (instead of when the quote was created). That means any delays in the system up to that point in time are forever erased and hidden. This practice needs to stop immediately. The original timestamp created by the exchange when the quote record was first created must be retained throughout the life of the quote. We do not advocate adding another timestamp. The original timestamp created by the exchange at the time a quote is created should be what is transmitted in the quote message timestamp field. The end user, the trader or investor, does not care where the delay occurs. They only want to know the existence and extent of any delay. Adding another timestamp would increase the size of every quote message and require unnecessary software changes on every system processing these messages. "
I don't think the two changes proposed are an onerous load on any party. It should provide transparency on price discovery and allow all participants to make informed decisions based on higher integrity market data. The way timestamps are managed now is nothing more than a high tech 3 card monty.
The Timestamp issue as addressed in the Nanex proposal:
"Require the time stamp field in all quote messages to be set to the time the quote was created at each exchange, instead of when it is transmitted by the network processors (SIP). This will allow all downstream users to accurately compute the age of each quote."
"Everyone will be able to compute the exact age or delay in every quote (chalk it up to modern computing, trust us on this), and therefore determine if there is enough time to execute against it. "
2. "Currently, every quote message has a timestamp field which is filled (replaced) by CQS when the quote is ready for transmission (instead of when the quote was created). That means any delays in the system up to that point in time are forever erased and hidden. This practice needs to stop immediately. The original timestamp created by the exchange when the quote record was first created must be retained throughout the life of the quote. We do not advocate adding another timestamp. The original timestamp created by the exchange at the time a quote is created should be what is transmitted in the quote message timestamp field. The end user, the trader or investor, does not care where the delay occurs. They only want to know the existence and extent of any delay. Adding another timestamp would increase the size of every quote message and require unnecessary software changes on every system processing these messages. "
Quote from Random.Capital:
Which timestamp?
There is a timestamp when an order hits the edge of the exchange's infrastructure.
There is a timestamp when the order hits the matching engine.
There is a timestamp when the order exits the matching engine (ie, book update or trade event). The differential between the this timestamp and the above timestamp is not a constant, and will be a function of both message traffic quantity and where in the book the order lands.
There is a timestamp when the golden market data feed for this event is actually generated.
There is a timestamp when the golden feed hits the actual distribution point.
How are you going to synchronize everybody's computers so the timestamp has meaning in the absolute sense? At these timescales, you're not, because it's impossible without massive expense. So now the timestamp is a relative measure between the receiver and the sender. Which means software changes on the receiver side to continuously recalibrate, because non-colo connection speed/throughput are filled with all kinds of variances when talking about these kinds of timescales.
That sure doesn't sound like fun.
Are your Java-based systems deterministic enough that you can count on milisecond-scale repetition? Under a variety of market conditions? Very few are.
But this all begs the question of what problem is being tackled. Because on anything resembling a liquid stock/future, it's easy to get consistent fills if you're simply willing to accept one tick off the BBO. So for "investors", this is all a total non-issue anyway - which means we're really talking about Spy vs Spy - ie, there are no White Hats.
If the concern is having too many quotes of dubious value for the general trading audience on the main feed, there is a simpler solution. Give the ultra-fast folks a unique Participant ID for their fast algos (eg, add "FAST" to their root PID, or etc), and filter the golden market data feed to strip out any update with those identifiers for recipients who place no value on those quotes. Customers can decide for themselves which feed makes the most sense.
Concept is already in the works. Regulation will require a specified hold time for an Oder before a cancel is allowed. Also a fee for high order to cancel ratios. And loss of rebates to firms with excessive order to cancel ratios. Most head way is occurring in Europe right now.
Once the consolidated audit trail is put in place it will greatly reduce the numbers of orders. It's going to cost money to store all that order data and that cost will be paid by brokers, traders, hft firms, etc. Hfts that send out thousands of orders and cancels won't survive. You and me wont even notice the added cost.
Once the consolidated audit trail is put in place it will greatly reduce the numbers of orders. It's going to cost money to store all that order data and that cost will be paid by brokers, traders, hft firms, etc. Hfts that send out thousands of orders and cancels won't survive. You and me wont even notice the added cost.
These proposals I have read from various sources over the last few weeks.
There is the idea of requiring orders to post for 500 milliseconds until it can be canceled. I know that Nasdaq and DirectX will reduce rebates to the specific frim when on average they cancel 100 orders per 1 executed order starting this summer. Nasdaq will charge btw .01 - 1 cent per order depending on the ratio. DirectX is reducing rebates by just 3%.
Regulation seems focused on establishing minimum resting periods for orders and limits on the quote to cancel ratio. Also the ideas of establishing a single, central hub that will update quotes unifromally across exchanges. Exchanges will no longer be allowed to transmit data to outside lines but only to the central market data center. Effectively eliminating co-location servers at each exchange.
The consolidated audit trail will slow HFT's down the most. It will cost $4billion to implement and $2billion to run each year. This will be paid for by a small 'tax' on all order messaging. We are talking about a fraction of a cent but for algo's that send thousands of messages a second, the costs will put them under. Also the CAT will finally illustrate just what kind of impact and manipulation all the excessive quoting has on the market.
The CAT will be approved by the end of 2012 from SEC sources.
Sorry I cant recall more info but I will post again once I do.
There is the idea of requiring orders to post for 500 milliseconds until it can be canceled. I know that Nasdaq and DirectX will reduce rebates to the specific frim when on average they cancel 100 orders per 1 executed order starting this summer. Nasdaq will charge btw .01 - 1 cent per order depending on the ratio. DirectX is reducing rebates by just 3%.
Regulation seems focused on establishing minimum resting periods for orders and limits on the quote to cancel ratio. Also the ideas of establishing a single, central hub that will update quotes unifromally across exchanges. Exchanges will no longer be allowed to transmit data to outside lines but only to the central market data center. Effectively eliminating co-location servers at each exchange.
The consolidated audit trail will slow HFT's down the most. It will cost $4billion to implement and $2billion to run each year. This will be paid for by a small 'tax' on all order messaging. We are talking about a fraction of a cent but for algo's that send thousands of messages a second, the costs will put them under. Also the CAT will finally illustrate just what kind of impact and manipulation all the excessive quoting has on the market.
The CAT will be approved by the end of 2012 from SEC sources.
Sorry I cant recall more info but I will post again once I do.
Quote from mastertrader456:
Also the ideas of establishing a single, central hub that will update quotes unifromally across exchanges. Exchanges will no longer be allowed to transmit data to outside lines but only to the central market data center. Effectively eliminating co-location servers at each exchange.
[/B]
To summarize better. All data feeds will come from the central market server. Exchanges would no longer be able to offer direct lines as they do now. They must send all data to the central market server.
There is the attempt to minimize latency advantages between market participants since the biggest and wealthiest institutions are the only ones able to take advantage of that.
Sounds like OPRA feed... Pretty easy to identify any latency advantage over OPRA if you have DMA. Just measure the lag between your direct feed and the OPRA feed.
The fact that trades are allowed to be reported up to 3 minutes after the fact and not coded as being late is another issue. 3 minutes is an eternity and anything not instantly reported should be coded as late.
When you process messages you can see the order matching / reporting lag.
TIMESTAMP LATE FLAG ASK BID TRADE VOLUME
2012-04-27 09:45:43.950 1 140.29 140.28 140.2699 13644507
2012-04-27 09:48:54.300 1 140.12 140.11 140.09 15217244
2012-04-27 09:49:07.850 1 140.12 140.11 140.08 15550417
2012-04-27 09:55:05.400 1 140.14 140.13 140.1 18049454
2012-04-27 09:56:42.800 1 140.2 140.19 140.21 19089215
2012-04-27 10:01:35.825 1 140.05 140.04 140.025 21514314
2012-04-27 10:01:54.225 1 139.91 139.9 139.89 22061910
2012-04-27 10:02:08.375 1 139.93 139.92 139.94 22571203
2012-04-27 10:04:44.275 1 139.97 139.96 139.99 23842646
2012-04-27 10:28:56.725 1 140 139.99 139.98 34862836
2012-04-27 10:30:07.600 1 140.03 140.02 140.045 35492530
2012-04-27 10:32:08.525 1 140.05 140.04 140.06 36087820
2012-04-27 10:32:20.750 1 140.07 140.06 140.085 36268848
2012-04-27 10:46:12.400 1 140.06 140.05 140.08 42597554
2012-04-27 10:53:16.500 1 140.17 140.16 140.185 45720649
2012-04-27 10:54:15.400 1 140.19 140.18 140.2 45933777
2012-04-27 11:42:42.125 1 140.27 140.26 140.28 59632025
2012-04-27 12:05:18.825 1 140.3 140.29 140.265 63123564
The fact that trades are allowed to be reported up to 3 minutes after the fact and not coded as being late is another issue. 3 minutes is an eternity and anything not instantly reported should be coded as late.
When you process messages you can see the order matching / reporting lag.
TIMESTAMP LATE FLAG ASK BID TRADE VOLUME
2012-04-27 09:45:43.950 1 140.29 140.28 140.2699 13644507
2012-04-27 09:48:54.300 1 140.12 140.11 140.09 15217244
2012-04-27 09:49:07.850 1 140.12 140.11 140.08 15550417
2012-04-27 09:55:05.400 1 140.14 140.13 140.1 18049454
2012-04-27 09:56:42.800 1 140.2 140.19 140.21 19089215
2012-04-27 10:01:35.825 1 140.05 140.04 140.025 21514314
2012-04-27 10:01:54.225 1 139.91 139.9 139.89 22061910
2012-04-27 10:02:08.375 1 139.93 139.92 139.94 22571203
2012-04-27 10:04:44.275 1 139.97 139.96 139.99 23842646
2012-04-27 10:28:56.725 1 140 139.99 139.98 34862836
2012-04-27 10:30:07.600 1 140.03 140.02 140.045 35492530
2012-04-27 10:32:08.525 1 140.05 140.04 140.06 36087820
2012-04-27 10:32:20.750 1 140.07 140.06 140.085 36268848
2012-04-27 10:46:12.400 1 140.06 140.05 140.08 42597554
2012-04-27 10:53:16.500 1 140.17 140.16 140.185 45720649
2012-04-27 10:54:15.400 1 140.19 140.18 140.2 45933777
2012-04-27 11:42:42.125 1 140.27 140.26 140.28 59632025
2012-04-27 12:05:18.825 1 140.3 140.29 140.265 63123564
Quote from mastertrader456:
To summarize better. All data feeds will come from the central market server. Exchanges would no longer be able to offer direct lines as they do now. They must send all data to the central market server.
There is the attempt to minimize latency advantages between market participants since the biggest and wealthiest institutions are the only ones able to take advantage of that.