Should we decimalize futures?

[JayF]

Throughout our approximately 20 years of real-time data broadcasting, we have always adhered to each exchange's specifications for deciding whether or not to decimalize futures symbols. In seeing the trend shift more towards displaying futures symbols as a decimalized value (excepting T-Bonds, T-Bills, etc.,) we would like to revisit this idea with our users and see what you want. We are starting a poll for exactly this purpose. Please be aware that if decimals are implemented for futures symbols, there will not be an option to put them back to a non-decimalized format.

Thank you in advance for your vote and your opinion!

[tbodnar]

During those days when some users (including me) WERE seeing futures in decimals the difficulty I had was this. The y-axis for ES might have been labeled 980.00, 982.50, 985.00 with 2 decimal places shown (if I recall correctly), while the last-traded price, which was also displayed on the y-axis, might have been shown as 982, 982.25, 982.5, 982.75, or 983, depending on whatever it was. So the number of decimals in the lasted-traded price could be 0, 1, or 2 depending on the number of decimals required. This caused the last-traded price to sometimes have fewer decimal places that the labels on the y-axis, the result being that the last-traded price did not always completely overlay the price labels on the y-axis, causing me some visual confusion.

By the way, I voted to leave it as it is. If the vote goes the other way and decimals are added, please also address the problem I have just described. Thank you.

[zigzag]

futures dec

Am I right to assume that this change doesn't apply to e-minis? Aren't they already decimilized?

[Essan]

How would you decimalize currency futures contracts? Would the yen be 8633 (current format) 0.8633 or 0.008633?

Would t-bonds, notes remain in 32nds?

Why not remain consistent with the respective exchange format?

[Chuck]

Decimals

Just to be clearer here, it would only be for contracts that already trade in decimals that are displayed as whole numbers.

So the emini for es z3 that shows 102750 now would be displayed as 1027.50.

[ACM]

FWIW I too voted to keep the display as is.
Firstly because it reflects how I see prices on my Globex terminal and secondly because I fail to see what advantages, if any, there are in switching to decimals.
On the contrary I believe we end up with a confusing display of futures where treasuries for example will be displayed one way and equity indices in another. Also not addressed is how the currencies will be displayed and how the decimalization will impact the labels which will end up taking more real estate away from the charts.
Alex

[MR]

I would normally vote, YES, until I read my friend Jay’s comment-- "Please be aware that if decimals are implemented for futures symbols, there will not be an option to put them back to a non-decimalized format." It raises a flag of concern because I can foresee definite problems arising from a change with limited or no recourse to correct unanticipated obstacles.

If we had a flexible framework to work through a decimal conversion process for those contracts already trading in decimals this could generate more excellent improvements.

I am open to any idea at this point.

In addition, being like the over 40% of all 'numerically and visually challenged' [dyslexic type] futures traders, the current futures contract price system has always been a challenge. For over 15 years I have desperately wished for a better way to deal with converting futures contract values quickly into usable information.

I am in need of this idea.

Decimalization is going to evolve because international futures and stock markets continue to struggle for greater efficiencies worldwide. This debate will ultimately lead to a decimal standard once political and economic forces converge.

I can foresee either regulators, exchanges or market conditions finally dictating a change anyway.

Introducing Globex was not a seamless process in the early stages, but once it got rolling it was almost unstopable. It now seems welcomed and a successfully embraced idea.

Question-- Could we maintain the existing standard, introduce a experimental decimal standard, and then maintain the two formats at the same time under different symbols? Could we allow co-existence within a data stream until after a prolonged and well-tested conversion process? This would allow eSignal to work through all major and minor issues in a practical, agreeable way? We could drop the current standard once confident it meets the needs of the consumer, exchanges, the realities of market conditions? (Forgive me if this is not a practical idea, I honestly don’t know.)

If market conditions are against current conversion, I would still vote we begin an experimental process where we research further how to seamlessly enact a Futures market decimal conversion at a future date.

Decimal conversion is an idea I believe will eventually be forced either by exchanges, regulators or market conditions. When it finally happens we will witness a very sudden sea change in attitude and will not be prepared for this new need and the problems. I say we prepare to lead the way.

I vote in favor of decimalization for some futures contracts, but only if it doesn’t make us a radically different standard and if it can be done in a way it doesn't initially backfire.

[JayF]

Marc,

Thanks for the great post!

To answer your questions, my understanding of the way this would be implemented is that it would be done from a .tab file (I believe specs.tab) instead of changing the data feed, and that file would automatically be downloaded from our servers. Certainly the ideal would be to give the choice to each user as to whether or not to display decimals, but my understanding is that this would be quite an undertaking given the way eSignal and the Data Manager is currently structured.

[tbodnar]

If I had to have ES displayed in decimals, I would like the option to be able to ALWAYS see 2 decimal places, even if they are ".00" or ".50". I would not be comfortable with the visual effect that would result from jumping between 0, 1, or 2 decimal places with every print.