This document is a collection of thoughts and analysis to optimize FIX for High Frequency Trading activity. Lowering latency and transit-time.

1. High Frequency FIX Analysis and Proposals for HFT FIX December 2010

2. ABTRACT This document is a collection of thoughts and analysis to optimize FIX for High Frequency Trading activity. Lowering latency and transit-time. 2

4. L2 Cache access 7 ns

5. Main memoryacess 100 ns

6. Compress 1K with cheap algo 3 000 ns

7. Send 2K bytes on 1Gbps network 20 000 ns

8. Read 1M sequentiallyfrommemory 250 000 nsFigures comingfromGoogle’s Jeff Dean talk atStanford in 2010. 3

9. WHAT WE NEED TO OPTIMIZE 4 Trading System A Trading System B Event Network Event encode decode Reduce transit-time

10. WHAT WE NEED TO OPTIMIZE Encoding Event*  Stream of bytes Network transit Smaller the stream of bytesis, faster the transit it. Decoding Stream of bytes Event* *Event isat the application level. Not an object of the FIX engine. 5

12. Decoding

13. Message sizeIOW:Useless to have ultra-tiny message if encoding or decoding are heavily slow.

14. 7 Chapter 1 Integrationwithin the protocol

15. 8 INTEGRATION WITHIN FIX 5.0 TODAY FIX Applicative messages FIX Transport FIXT 1.1 JMS …

16. INTEGRATION WITHIN FIX 5.0 PROPOSAL Existing CODEC: Tag=Values<SOH> FIX Applicative messages We are here FIX Codec FIXC 1.0 … FIXHFT 1.0 FIX Transport FIXT 1.1 JMS … 9

17. 10 INTEGRATION WITHIN FIX 5.0 Wecancreate and evolve the CODEC implementation (v1.0, v1.1, etc…). We open the door to differentimplementation of CODEC => More innovation captured over time.

18. 11 Chapter 2 The Header and Trailer

19. 12 BENCHMARK MESSAGE All testing has been donewith the following FIX message – tinylimitorder in FIX 4.2: 8=FIX.4.2|9=177|35=D|49=FIXSENDER|56=ULTEST|34=4209|52=20101029-10:11:51.890|1=1374390|55=DE0005937007|48=DE0005937007|22=4|54=2|114=N|38=1|59=0|40=2|21=1|44=200|15=EUR|100=DE|11=1288346559187|10=025| 200 bytes

21. 10 bytesminimum possible : « 49=F|56=U| »)(Again 5-10% of total size)

22. 14 HEADER SIZE Tag 52 (SendingTime) Sending time isusefull to avoiddelayed and dangerousorder to reach the market. But, 25 bytesistoomuch (more than 10% of message size) « 52=20101029-10:11:51.890| »

23. 15 Encoding Tag 9 (BodyLength) and Tag 10 (Checksum) Tag 9 needs Body to beencoded, Tag 10 needs Tag 9. All thesesteps are expensive and requiredifferentmemoryiterations and transfert. Tag 9 + 10 = ~13 bytes (again more than 5% of the benchmark msg) Event 1) Encode Body Socket 4) Send to socket Buffer 2) Encode Length 3) Encode Checksum

24. 16 Encoding Tag 9 (BodyLength) and Tag 10 (Checksum) Weshouldbe able to stream the encoding as much as possible. Encoding Checksum iswaytoo slow becauseit scan full message. Atthis stage memory scan make a bigdifference. Cf. Slide 2 Socket Event Stream encoding

25. 17 Decoding Tag 9 (BodyLength) and Tag 10 (Checksum) On the decoding end, Tag 9 and Tag 10 are onlyused for check integritybecause message are cutbetween Tag 8 and Tag 10. Again buffer isscanned for Checksum validation. Costtoomuch. I guesswecangetrid of thisintegritychecks and rely on the transport directly.

26. 18 SUMMARY If you combine all this: Header+Trailer = 38% of the message size So, Theorically, Header+Trailer = 38% of the encoding time Because of checksum cost, I guessmore than 40% Body 116 bytes (62%) Header + Trailer 77 bytes (38%)

27. 19 PROPOSAL : All mandatory tag in structuredbinary: Binaryisfaster to encode and decode

28. 20 PROPOSAL Example: 8=FIX.4.2|9=177|35=D|49=FIXSENDER|56=ULTEST|34=4209|52=20101029-10:11:51.890|1=1374390|55=DE0005937007|48=DE0005937007|22=4|54=2|114=N|38=1|59=0|40=2|21=1|44=200|15=EUR|100=DE|11=1288346559187|10=025| Becomes: <NEWHEADER>1=1374390|55=DE0005937007|48=DE0005937007|22=4|54=2|114=N|38=1|59=0|40=2|21=1|44=200|15=EUR|100=DE|11=1288346559187| 200 bytes -> about 130 bytes About 35% smaller. Faster to encode and decodebecausebinarybased.

29. 21 Chapter 3 BinaryEncoding

31. Faster to decode

33. 24 PROPOSAL : Encode fields in a compact binaryform Field Header = 1 byte = 8 bits

34. 25 PROPOSAL : Encode fields in a compact binaryform Field Header / Tag Value Encoded Format (7 bits)

35. 26 PROPOSAL : Encode fields in a compact binaryform Field Header / Tag Value Encoded Format (7 bits)

36. 27 PROPOSAL : Encode fields in a compact binaryform Field Header / Tag Value Encoded Format (7 bits) What about Boolean and Char? They are heavilyused in FIX Protocol – weneedsomethingefficent! Withthis, char encodingdon’tneed tag value – it’s all there.

37. 28 PROPOSAL : Encode fields in a compact binaryform Field Header / Tag Value Encoded Format (7 bits) There isavailable values for more ideas/values: You to fill in.

38. 29 PROPOSAL : Encode fields in a compact binaryform Benchmark message body: 1=1374390| -> 10 bytes (String) or 6 bytes (Integer 4 bytes) 55=DE0005937007| -> 15 bytes (String) 48=DE0005937007| -> 15 bytes (String) 22=4| -> 2 bytes (Char) 54=2| -> 2 bytes (Char) 114=N| -> 2 bytes (Char/Bool) 38=1| -> 2 bytes (Char) 59=0| -> 2 bytes (Char) 40=2| -> 2 bytes (Char) 21=1| -> 2 bytes (Char) 44=200| -> 3 bytes (Integer 1 byte) 15=EUR| -> 6 bytes (String) 100=DE| -> 5 bytes (String) 11=1288346559187|-> 16 bytes (String) Body size from 116 bytes -> 80 or 84 bytes (-30%) (NOTE: Tag 55 and 48 = 30 bytes of repetition)

39. 30 PROPOSAL – BIG PICTURE BENCHMARK FIX MESSAGE : Total = 200 bytes PROPOSAL: Total = 98 bytes (51% shaved) Body 116 bytes (62%) Header + Trailer 77 bytes (38%) NEW BODY ~84 bytes (86%) NEW HEADER ~14 bytes (14%)

40. 31 Chapter 4 How it compares to Compression?

41. 32 COMPRESSION with LZF LZF = Fast and lightweight LZ algorithm LZ = Lempel-Ziv = Compression of repetitions Withoutpredefineddictionary: Message size = 189bytes Withpredefineddictionary: Not doneyet

42. 33 COMPRESSION withHuffman Huffman = Most used chars use less bits WithoptimizedHuffmantree for the benchmarked message: Message size = 103 bytes(-49%) But huffmantreeneeds to betransmitted! That’sanother 26 to 52 bytes! A new huffmantreemay not beneeded on each message. Huffman tree: {.=1111111, -=11011000, X=1101101, U=1101110, T=1111101, S=1111010, R=1111000, N=1111011, |=011, L=11011001, I=1111001, F=1111100, E=11010, D=00110, ==010, :=1111110, 9=0010, 8=00111, 7=11100, 6=1101111, 5=1100, 4=1010, 3=11101, 2=1011, 1=000, 0=100}

43. 34 COMPRESSION with ZLIB ZLIB = LZ + Huffman Single message: Message size = 132 bytes (-34%) (Toomuchoverheadgiven the size of the message)

44. 35 COMPRESSION Compression is an additionalcost to encoding and decoding. If FIX tag=value formis slow thanit’s not going to improveitat all. Message sizes are not impressive – Theydon’t match the encoded format proposed in this document. Trading System A Trading System B Compress Uncompress Event Network Event encode decode

45. 36 COMPRESSION Wemayneed to investiguate compression of individual strings using a predifinedhuffmantree. A lot of FIX strings are usingnumbers and uper case letters. Good for IDs, like CLOIRDID, ORDERID, ORIGCLORDID, ACCOUNT, SYMBOL, ISIN Codes, RIC Codes, etc… But, thiswill impact encoding and decoding times…

46. 37 Chapter 5 New Message Types

48. Increase/Decrease (qty)

49. Cancel all my open ordersNeeds to bedesigned by HFT firmsbased on theirneeds

50. 39 Chapter 6 Prepared messages

51. 40 PREPARED MESSAGES SeePrepared Messages as PreparedStatements in the SQL world. Pre-filled and parametrised messages that the destination isready to receive and process. This alsomeansthatsome optimisation / pre-processingcanbedone up-front on the receiving end.

52. 41 PREPARED MESSAGES Prepared Message: <MESSAGE HEADER> -> Unchanged 1=1374390| -> 10 bytes (String) or 6 bytes (Integer 4 bytes) 55=?| -> 2 byte (Parameter 1) 48=?| -> 2 byte (Parameter 2) 22=4| -> 2 bytes (Char) 54=?| -> 2 byte (Parameter 3) 114=N| -> 2 bytes (Char/Bool) 38=?| -> 2 byte (Parameter 4) 59=0| -> 2 bytes (Char) 40=2| -> 2 bytes (Char) 21=1| -> 2 bytes (Char) 44=?| -> 2 bytes (Parameter 5) 15=EUR| -> 6 bytes (String) 100=DE| -> 5 bytes (String) 11=?| -> 2 bytes (Parameter 6) 65535=123 -> Prepared message ID Tag 65535 (couldbeanything) is the prepared message ID used for execute.

53. 42 PREPARED MESSAGES Once prepared, Message to executeis: PreparedMsg ID 123 -> 2 bytes Parameter 1 : Symbol DE0005937007 -> 14 bytes (String) Parameter 2 : SecurityID DE0005937007 -> 14 bytes (String) Parameter 3 : Side 2 -> 1 bytes (Char) Parameter 4 : Quantity 1 -> 2 bytes (Integer) Parameter 5 : Price 200 -> 2 bytes (Integer) Parameter 6 : ClOrdId 1288346559187 -> 15 bytes (String) Executed message = 64 bytes Execute Message ~50 bytes NEW HEADER ~14 bytes

54. 43 PREPARED MESSAGES A blackboxdoing Pairs TradingcanPrepare Stock and Side: PreparedMsg ID 123 -> 2 bytes Parameter 1 : Quantity 1 -> 2 bytes (Integer) Parameter 2 : Price 200 -> 2 bytes (Integer) Parameter 3 : ClOrdId 1288346559187 -> 15 bytes (String) Executed message = 35 bytes (!) Execute Message ~21 bytes NEW HEADER ~14 bytes

55. 44 PREPARED MESSAGES Prepared Messages givevery good resultswithoutremovinganything of the FIX protocol. Prepared Messages fits HTF verywellsince instruments and strategies are repetitive and ordertopologyisknownupfront. Note: Message size issomuchreducethatwemayneed to work on a more compact form for tag 11 (ClOrdId) and tag 41(OrigClOrdId). Indeed, in my last example, 15/35 bytes are related to tag 11.

56. 45 PREPARED MESSAGES Another good effect of prepared messages isthat the receiving system canprepareobjects and data to optimizeprocessing of execute message. This canoptimize the processing of the message within the application itself – evenfurtherthan the decoding end (Exactlylikepreparedstatements in SQL are fasterwithin the Database). Trading System A Trading System B Prepared Message Event Event encode decode Execute Message

57. 46 Conclusion

59. Encoding & Decoding are faster (a lot of binaryform / no checksum)

60. It’s simple – nobodyneedsPhD

61. FIX Protocol has not been denatured.Prepared Messages apart, no changes required to any application alreadyusing a FIX Engine. A single « HFT=yes » option couldturnthis on in FIX Engines. This coulddramaticallyreduceinvestment of the industry and boostadaption.

62. TO BE CONTINUED… Contact : Georges Gomes georges.gomes@ullink.com Merry Christmas and Happy New Year 2011