FIXT + FIX 5.0 in the real world?

, ,
1

Imported from previous forum

2

Hi All,

I’ve been wondering how many people are actually using all of the features of FIXT+FIX in the real world? Although I like the separation of the session layer from the application layer, in the context of transporting non-FIX messages, and even regular FIX messages if the layer separation was really being taken to heart, I wonder how much of this just makes things more complicated from the perspective of people who are already managing existing FIX engines/systems?

I know that even from the greenfield project perspective, for example the VersaFix OSS engine we’ve been developing, actually implementing the FIXT+FIX stuff can be pretty complicated, so I wonder how many people are actually retrofitting all of this into their existing products - is this really being well received across all the firms that have existing engines and products that are used to dealing with FIX messages from the 4.2-4.4 perspective?

3

Hi Russ,

I do not think a message in a discussion forum would give any good picture of adoption of FIXT + FIX in the real world. Instead FPL office could send out a survey / questionnaire to all member firms http://fixprotocol.org/members/ and all companies listed as FIX Products and Vendors http://fixprotocol.org/products/all and compile the results of such a survey. Questions in the survey could be like

Q1. Which versions of FIX do you support (select all that apply)
{list all versions here}

Q2. What asset classes do you deal with (select all that apply)
{list all asset classes here}

Q3. Does your firm support any Non-FIX protocols

Q4. Does your firm use FIX internally for communication between systems

Q5. Does your firm use FIXML internally for communication between systems

Q6. Does your firm plan an upgrade of FIX version ? Yes / no

Q7. If you answered yes to Q6 which version(s) are you planning to support(select all that apply)
{list all versions here}

Q8. Does your firm’s FIX systems use Message Types from higher versions ? Yes / no

Q9. Does your firm’s FIX systems use Tags from higher versions ? Yes / no

Q10. Does your firm’s FIX systems use Custom Message Types ? Yes / no

Q11. Does your firm’s FIX systems use Custom Tags ? Yes / no

We could discuss in this Thread what additional questions could be asked. Response to such a survey could be classified by organization type and that would provide an insight into usage of FIXT + FIX

In my previous project, I was given the task of analyzing upgrade of the FIX.4.0 US Equities and options only Broker Trading application (takes NewOrderSingle from clients and routes them to exchanges & forwards ExecutionReports received from Exchanges to clients) upgraded to FIX.4.2+ to add support for complex options using NewOrderMultileg, FixedIncome etc. I suggested FIXT.1.1 and the management’s view was FIXT.1.1 is too complex which does not add any benefit to the business.

Regards,
K. Mahesh

Hi All,

I’ve been wondering how many people are actually using all of the
features of FIXT+FIX in the real world? Although I like the separation
of the session layer from the application layer, in the context of
transporting non-FIX messages, and even regular FIX messages if the
layer separation was really being taken to heart, I wonder how much of
this just makes things more complicated from the perspective of people
who are already managing existing FIX engines/systems?

I know that even from the greenfield project perspective, for example
the VersaFix OSS engine we’ve been developing, actually implementing the
FIXT+FIX stuff can be pretty complicated, so I wonder how many people
are actually retrofitting all of this into their existing products - is
this really being well received across all the firms that have existing
engines and products that are used to dealing with FIX messages from the
4.2-4.4 perspective?

4

[ original email was from John Greenan - john.greenan@alignment-systems.com ]
Possible to send out survey, but how many banks will answer with the whole truth??

I’ve often found that these sorts of surveys convey the desired future sstate of the responder rather than the ground truth…

Hi Russ,

I do not think a message in a discussion forum would give any good
picture of adoption of FIXT + FIX in the real world. Instead FPL office
could send out a survey / questionnaire to all member firms
http://fixprotocol.org/members/ and all companies listed as FIX Products
and Vendors http://fixprotocol.org/products/all and compile the results
of such a survey. Questions in the survey could be like

Q1. Which versions of FIX do you support (select all that apply) {list
all versions here}

Q2. What asset classes do you deal with (select all that apply) {list
all asset classes here}

Q3. Does your firm support any Non-FIX protocols

Q4. Does your firm use FIX internally for communication between systems

Q5. Does your firm use FIXML internally for communication
between systems

Q6. Does your firm plan an upgrade of FIX version ? Yes / no

Q7. If you answered yes to Q6 which version(s) are you planning to
support(select all that apply) {list all versions here}

Q7. Does your firm’s FIX systems use Message Types from higher versions
? Yes / no

Q8. Does your firm’s FIX systems use Tags from higher versions ? Yes /
no

Q9. Does your firm’s FIX systems use Custom Message Types ? Yes / no

Q10. Does your firm’s FIX systems use Custom Tags ? Yes / no

We could discuss in this Thread what additional questions could be
asked. Response to such a survey could be classified by organization
type and that would provide an insight into usage of FIXT + FIX

In my previous project, I was given the task of analyzing upgrade of the
FIX.4.0 US Equities and options only Broker Trading application (takes
NewOrderSingle from clients and routes them to exchanges & forwards
ExecutionReports received from Exchanges to clients) upgraded to
FIX.4.2+ to add support for complex options using NewOrderMultileg,
FixedIncome etc. I suggested FIXT.1.1 and the management’s view was
FIXT.1.1 is too complex which does not add any benefit to the business.

Regards,
R. Mahesh

Hi All,

I’ve been wondering how many people are actually using all of the
features of FIXT+FIX in the real world? Although I like the separation
of the session layer from the application layer, in the context of
transporting non-FIX messages, and even regular FIX messages if the
layer separation was really being taken to heart, I wonder how much of
this just makes things more complicated from the perspective of people
who are already managing existing FIX engines/systems?

I know that even from the greenfield project perspective, for example
the VersaFix OSS engine we’ve been developing, actually implementing
the FIXT+FIX stuff can be pretty complicated, so I wonder how many
people are actually retrofitting all of this into their existing
products - is this really being well received across all the firms
that have existing engines and products that are used to dealing with
FIX messages from the
4.2-4.4 perspective?

5

John, Russ,

Instead of a survey sent out to member firms and FIX product vendors, I was thinking about an online survey sent out to all email ids (FIX users) registered in http://FIXProtocol.org

Google search of “Online surveys” gave tooo many results

This could include additional questions like

Q1. Select options below which best describe your involvement with FIXProtocol
Student
Programmer
Business analyst
QA analyst / Tester
Project manager
CIO / CTO or higher positions
Recruiter / Interviewer

Q2. How long have you been involved with FIX
less than 1 year
1 to 5 years
more than 5 years

Q3. How would you rate your knowledge of FIXProtocol on a scale of 1 to 10 (1 being beginner and 10 being expert)

Online surveys can be very dynamic by permitting additional questions be be asked based on responses, for example people who select FIXT.1.1 as an option to either of the below questions

Q1. Which versions of FIX do you support (select all that apply)
{list all versions here}

Q7. If you answered yes to Q6 which version(s) are you planning to support(select all that apply)
{list all versions here}

could be given additional questions

Q8. Describe in your own words what do you like most about FIXT.1.1

Q9. Describe in your own words what do you not like about FIXT.1.1

These questions would present text boxes for response. After the survey is closed, FPL could publish these responses as anonymous without showing any personal identification information like name or email id etc.

Q10. How would you rate complexity of FIXT.1.1 on a scale of 1 to 10 (1 being not at all complex and 10 being very complex)

Q11. Is FIXT.1.1 being used to transport non FIX data ?

Since the results / statistics released after the survey would not include any personal information (name / email id etc) of the respondents, I would expect most people would give true / near true answers.

Now the big question is how to attract most registered used of this website to participate. Offer couple of prizes which would be selected by lottery (has no relation to responses) from list of all people who participated in the survey.

Regards,
K. Mahesh

Possible to send out survey, but how many banks will answer with the
whole truth??

I’ve often found that these sorts of surveys convey the desired future
sstate of the responder rather than the ground truth…

6

I think polling each FIX member organization and giving them some form of proportional representation on important strategic decisions makes considerable sense.

I am submitting a proposal to permit firms without the need for application version independence or transport independence to simply use 8=FIX.5.0, 8=FIX.5.0SP1, 8=FIX.5.0SP2, etc.

We could then let the industry choose for themselves.

The alternative is to come out with a FIXT.1.2 to address limitations in the current FIXT.1.1.

Either way we end up with two approaches that must be implemented and supported - why not make that second approach match the original simple and successful approach taking with FIX.2.7-FIX.4.4?

It is time for practicality so that firms can start to easily access the very valuable business functionality locked within FIX.5.0.

This issue can literally be changed with a stroke of a pen.

7

Hi Jim,

This sounds like a good idea that firms who do not want application version independence or transport independence simply use 8=FIX.5.0, 8=FIX.5.0SP1, 8=FIX.5.0SP2, etc.

Regarding FIXT.1.2, the following are my thoughts

  1. Let all Session messages (Heartbeat, TestRequest, ResendRequest, SessionLevelReject, SequenceReset, Logout and Logon) use BeginString 8=FIXT.1.2

  2. Logon message should contain a list of permitted application versions using

Start Component = PermittedApplVersions

Start Repeating Group = NoPermittedApplVersions

First Reqd field = PermittedApplVersion
Next Opt field = PermittedApplExtID
Next Opt field = PermittedCstmApplID

MsgTypeGrp component can be nested within this new Component PermittedApplVersions (or vice versa) so that versions can be specified by message type.

When a FIX engine receives a Logon message, it can validate this list with its counterparty configuration. If the FIX Engine finds a version it does not support / did not agree to support with the given counterparty, the FIX Engine can send a logout with 58=“Invalid version FIX.x.y”

  1. Define a new Enumeration Tag for Specifying the Logout reason and add it to Logout message. Some values that come to mind are

EndOfDay
Low Sequence number
FIX version not supported
etc.

4.1 Let all Application messages (too many to list here) use BeginString 8=FIX.n.m (without the “T”). If a Application message is received which has a BeginString which is not supported / not in the List 2. above, then a Session level reject can be sent with 58=“Invalid version FIX.n.m” and SessionRejectReason 373=18 Invalid/Unsupported Application Version.

4.2 Alternately, should the receipt of an unsupported version message be considered such a serious error that a Logout is issued ? In which case I would recommend adding 45 RefSeqNum and 372 RefMsgType to the logout message so that the counterparty who receives a logout due to an invalid version can dig thru their FIX log more easily.

4.3 Given this setup, there would be no need for ApplVerID(1128), DefaultApplVerID(1137) and related fields because each application message will have its version in begin string.

4.4 When a FIX Engine receives a message which does not BeginString 8=FIXT.p.q, the FIX Engine knows that it has to be an Application message and applies version versus message type check, applies all Session level validations, translates the FIX message into a message / object of the protocol between FIX Engine and Trading application and hands it over to the appropriate trading application. I assume there would be multiple trading applications behind the FIX Engine one for each supported version.

Regards,
K. Mahesh

I think polling each FIX member organization and giving them some form
of proportional representation on important strategic decisions makes
considerable sense.

I am submitting a proposal to permit firms without the need for
application version independence or transport independence to simply use
8=FIX.5.0, 8=FIX.5.0SP1, 8=FIX.5.0SP2, etc.

We could then let the industry choose for themselves.

The alternative is to come out with a FIXT.1.2 to address limitations in
the current FIXT.1.1.

Either way we end up with two approaches that must be implemented and
supported - why not make that second approach match the original simple
and successful approach taking with FIX.2.7-FIX.4.4?

It is time for practicality so that firms can start to easily access the
very valuable business functionality locked within FIX.5.0.

This issue can literally be changed with a stroke of a pen.

8

My recommendation is to not create a FIXT.1.2. Instead let people use 8=FIX.5.x if they don’t need application or transport independence.

9

Hi Jim,

But what about people who wish to implement application version independence or transport independence and have hit a road block implementing FIXT.1.1 due to its limitations ? I guess we need a survey to find out adoption of FIXT.1.1 + FIX.5.0 in the real world. Then we could decide if we need a FIXT.1.2 to overcome limitations of FIXT.1.1 :slight_smile:

Regards,
K. Mahesh

My recommendation is to not create a FIXT.1.2. Instead let people use
8=FIX.5.x if they don’t need application or transport independence.

10

What specific roadblocks are you referring to?

The issue I am aware of that can be resolved by enhancements to the repository have to do with what is contained in a FIXT repository and what is contained in the FIX5 repository and then how do you configure at FIXT+FIX5 repository either statically or dynamically.

The other issue is a controversial design feature that most vendors have addressed and that is the ability to specify DefaultApplVersID on the logon message which requires state information outside of a particular instance. This is Application Version Independence.

Hi Jim,

But what about people who wish to implement application version
independence or transport independence and have hit a road block
implementing FIXT.1.1 due to its limitations ? I guess we need a
survey to find out adoption of FIXT.1.1 + FIX.5.0 in the real world.
Then we could decide if we need a FIXT.1.2 to overcome limitations of
FIXT.1.1 :slight_smile:

Regards,
K. Mahesh

My recommendation is to not create a FIXT.1.2. Instead let people use
8=FIX.5.x if they don’t need application or transport independence.

11

Hi Jim,

The problem I found with loading the FIXT.1.1 + FIX.5.0 repositories together was that when loading MsgType.xml my engine was expecting MsgType to be unique, so after loading FIXT.1.1 repository, when it starts loading the FIX.5.0 repository, it complains about duplicate MsgType, throws an exception and exits. I handled it by manually editing the FIX.5.0 repository and removing all the Session level MsgTypes which were already present in FIXT.1.1 repository. This worked, but I found it a dirty solution and didn’t like it. I want to be able to deploy the FIX repository for a new version without any manual edits.

Regards,
K. Mahesh

What specific roadblocks are you referring to?

The issue I am aware of that can be resolved by enhancements to the
repository have to do with what is contained in a FIXT repository and
what is contained in the FIX5 repository and then how do you configure
at FIXT+FIX5 repository either statically or dynamically.

The other issue is a controversial design feature that most vendors have
addressed and that is the ability to specify DefaultApplVersID on the
logon message which requires state information outside of a particular
instance. This is Application Version Independence.

Hi Jim,

But what about people who wish to implement application version
independence or transport independence and have hit a road block
implementing FIXT.1.1 due to its limitations ? I guess we need a
survey to find out adoption of FIXT.1.1 + FIX.5.0 in the real world.
Then we could decide if we need a FIXT.1.2 to overcome limitations of
FIXT.1.1 :slight_smile:

Regards,
K. Mahesh

My recommendation is to not create a FIXT.1.2. Instead let people
use 8=FIX.5.x if they don’t need application or transport
independence.

12

The approach we have come up with is to create configuration rules that define how to handle fields that overlap. For instance MsgType=D should be unknown to FIXT.1.1 But MsgType=D is known for FIXT.1.1+FIX.[45]*

There are other fields. Phil and Ryan did separate analyses on this. We are close to having both: 1) Configuration rules for dynamically binding and 2) producing static, pre-configured repositories for use by member firms.