CODEWITHSUNDEEP
quickfixfix-protocolquickfixj
birkner
birkner

Reputation: 133

Slowing FIX Messages sent per second to accommodate vendor throttling requirement

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?

Upvotes: 1

Views: 1974

Answers (2)

rupweb
rupweb

Reputation: 3328

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.

Upvotes: 2

TheFIXGuy
TheFIXGuy

Reputation: 181

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.

Upvotes: 2

Related Questions