1

I send orders through FIX Protocol to a vendor. The vendor will only accept 100 FIX messages per second, and has requested that I throttle the orders I send them to not exceed this rate. I'm sure that I can write something to slow down the messages I send to them, similar to what I found here: Throttling method calls to M requests in N seconds

But I have two questions:

I would like to know if slowing down the rate of messages sent to a execution vendor or clearing firm is a common requirement in the industry, or is this a red flag that I am dealing with a rinky-dink vendor?

Is there some parameter to have QuickFix/J automatically slow down message throughput for me?

Community
  • 1
  • 1
birkner
  • 133
  • 9
  • I have never heard of such a throttling requirement, and my company has done quite a bit of FIX work. – Grant Birchmeier Mar 07 '14 at 23:41
  • It does seem fairly odd they ask customers to throttle their own message rates. What happens if you exceed the rate? Is there a limitation on message size? – Jason Mar 07 '14 at 23:52
  • That is the 1st time I have heard this. People try to make it faster, not slower. As much I ccan remember QuickFix/J doesn't allow throttling it down, you might have to do it yourself. – DumbCoder Mar 08 '14 at 12:08
  • CQG has a default maximum rate of 10 orders per second... and if exceeded it rejects the order with "Order Action rate exceeded". – Brian Rice Dec 28 '16 at 17:30

2 Answers2

2

It's to do with the fact the vendor has limited bandwidth and probably tens or hundreds of clients connecting. If you ask for pricing on, say, 100 instruments, and in a quiet market these all update once per second, then - per FIX connection - the vendor has to deal with 100 messages per second. OK fine, a FIX message is about how many bytes: say 500 characters at 1 byte per character = 500 bytes (someone correct me here). So 500 * 100 = 50,000 bytes per second per connection.

Then connect 100 clients = 5,000,000 bytes per second. Hmmm, still lots more room.

But in a busy market where quotes update 10 or 20 times per second. The numbers are multiplied by a factor of 10 or 20. You get network storms, long message queues, high CPU, messages lost, or the whole thing just goes down. Then the vendor will lose all it's business because they can't stay connected at the most crucial times.

OK there are probably a lot of solutions to this problem, but it's a description of a problem that has to be solved...

The other thing is the premier market makers for your vendor have to update their quotes according to market conditions. They will demand required bandwidth or simply reject trade executions. So there you have another trade off between sell side and buy side.

rupweb
  • 3,052
  • 1
  • 30
  • 57
  • 1
    Certainly with exchanges, as a market maker you may have a contract whereby you pay the exchange for the right to quote and in return they give you a 'capacity' in Quotes Per Second. – user1717259 Mar 10 '14 at 13:38
2

There are many systems that have difficulty handling large volumes of fills. It most likely has nothing to do with network bandwidth, but the underlying processing of messages on the application layer.

For example, some older systems rely on a relational database with table locking, and if executions are processed at a high volume, the entire Order Management System can have performance problems.

A brute force solution is to force the execution provider to either roll up executions or to throttle them.

Julien Roncaglia
  • 17,397
  • 4
  • 57
  • 75
TheFIXGuy
  • 181
  • 1
  • 1
  • 6