Are there open source FIX Simulators where the FIX SPEC each counterparty uses can be altered? [closed]

Question

Closed. This question does not meet Stack Overflow guidelines. It is not currently accepting answers.

---

Want to improve this question? Update the question so it's on-topic for Stack Overflow.

Closed 3 years ago.

Improve this question

Are there open source FIX Simulators where the FIX SPEC each counterparty uses can be altered?

For example, I may be a user at one end using FIX 4.2 with some custom tags, and I want to simulate a session with me and another user using say FIX 4.4 with some custom tags.

Answer 1

This answer is a little broader than your question, but it aims to get to the root of some misconceptions that I think your question is based on.

Two counterparties must use the same FIX version. e.g. a 4.2 party cannot talk to a 4.4 party.

Furthermore, automated conversion between FIX versions, say, converting 4.4 messages to 4.2 and back again, is not really possible. 4.4 has fields for features that 4.2 doesn't have.

Furthermore again, you can't even trust that two 4.4 exchanges will interpret any given message the same way. The two exchanges may use certain fields in rather different ways, and a given 4.4 message sent to, say, ICE will probably be interpreted differently than that same message sent to BARX. ICE will require different fields, or treat those fields differently, or has added custom fields to the spec that BARX doesn't use, and vice versa. It's been my experience that every commercial FIX interface uses a customized message/field dictionary that is different than all other vendors. They're just not concerned with interoperability with each other.

It's best to think if FIX as a transport protocol with a suggested dictionary of fields and messages. I've never worked with any counterparty that uses the default dictionary unaltered.

Answer 2

Just thought some clarification was in order for those not familiar with FIX. A FIX hub can (easily) translate and normalize FIX messages between various FIX protocols seamlessly so a client on FIX 4.0 can send orders to a sell side on FIX 4.2 without issue. All the application layer issues Grant is referring to is solved by certification. The FIX protocol is more than a guide but there is definitely room for interpretation (which is why you certify before enabling live trading connections). The protocol is more than just a suggestion, though as with any protocol, you can customize it as long as both parties both know the customizations (thus you would basically be using a new protocol based on FIX).

Agreed much of it is application layer, so you need to agree how the two parties will interpret information on a business level.

You definitely can take a higher protocol version (ex FIX 4.4) and send them to a lower protocol version (ex FIX 4.0). You can either lose fidelity of the information or you can pass the 4.4 tags along on the 4.0 message. This is all part of FIX message normalization, one of the main reasons you'd use a FIX hub.