FIX 4.0 float fields, 15 sig digits exceeded?

, ,
1

Imported from previous forum

2

[ original email was from David Emhardt - david.emhardt@tfn.com ]
I would like to know how people handle a float value that exceeds 15 significant digits in FIX 4.0. Round? truncate? reject? example tags AvgPx (6), Commission (12), LastPx (31), etc Do people reject price type fields that exceed the 99999999.9999 value? How do you handle a value like 123456789012.12345678 ??? The FIX 4.0 spec staetes "All float fields must accommodate up to 15 significant digits". But does not state how to handle values that are passed that exceed the 15 significant digits. Thanks for any info you can provide.

3

[ original email was from Ryan Pierce - rpierce@taltrade.com ]
> I would like to know how people handle a float value that exceeds 15 significant digits in FIX 4.0. Round? truncate? reject? example tags AvgPx (6), Commission (12), LastPx (31), etc Do people reject price type fields that exceed the 99999999.9999 value? How do you handle a value like 123456789012.12345678 ??? The FIX 4.0 spec staetes "All float fields must accommodate up to 15 significant digits". But does not state how to handle values that are passed that exceed the 15 significant digits. Thanks for any info you can provide.

This is a part of the FIX protocol that I strongly disagree with, and I believe many firms generally ignore it. FIX has removed several limits in the past when business needs have been hampered by those arbitrary limits (i.e. message length, number of messages in a session) to allow counterparties to define these things to suit their business requirements. This is one of the remaining arbitrary limits that I believe is best removed from the spec and left to business practice, and to a lesser extent, counterparties, to determine.

For instance, prior to decimalization, the smallest price unit in the US that could be reported for equities clearing was 1/256. If a customer entered an order to sell a stock at 10.0000000027, we’d round it to the nearest less competitive 1/256 unit, in this case 10.00390625. If the customer claims we’re not FIX compliant because we cannot store 15 significant digits without rounding, I’d be forced to agree, but at the same time I’d claim that this specification requirement is arbitrary and frivolous. If the FIX Protocol says that we should be able to support 15 decimal places of precision, and neither our clearing firm nor the NSCC/DTCC can accept that much precision, standard industry business practice obviously has to win out over protocol compliance.

At the same time, if a firm is trading some bizarre type of instrument where business practice for that industry sector requires more than 15 places of precision, then the FIX limit should be thrown out as well, and firms would be required to use what is standard for industry business practice.

What this means is:

  1. Unfortunately, engine vendors don’t have something definitive to work from. Hence they need to make sure they support at least as much precision as their most demanding customer wants, and a customer needs to make sure that the engine can support enough precision to meet their needs. This is no different from many other similar scenarios today. One could send a 124 gigabyte message and it would technically be FIX-compliant. But I doubt there’s a FIX engine that exists that could handle such a monstrosity. Then again, I doubt there’s a single business need at present for such a message.

  2. Counterparty testing of precision, as we have discovered, is important. For instance, the US equity precision prior to decimalization was 1/256. Archipelago hence chose, for fractional stocks prior to decimalization, to support a minimum price variation of 1/256. This means that a customer placing a limit order to buy at 10.125 could be filled at 10.00390625. As such, one of our required certification tests for all customers was to do this scenario, and verify that their engine and OMS could handle a fill of 10 1/256. Another test involved the customer stating the smallest precision they could handle sending, and then entering an order at that precision. For instance, one customer’s OMS allowed placing an order of 10 1/32. But instead of receiving 10.03125, their FIX engine rounded to 10.0313, which we considered a failure of the test since, depending on side, we’d be forced to round to something other than what the customer wanted.