Imported from previous forum
Hello
How should we implement our FIX engine when a NOS arrives with the 21=1 (DMA) and 58=?
Should we route this order directly to the exchange or does the text has priority over the HandlInst since text could be some HandlingInstructions for a broker?
Thanks
Hello
How should we implement our FIX engine when a NOS arrives with the 21=1 (DMA) and 58=?Should we route this order directly to the exchange or does the text has priority over the HandlInst since text could be some HandlingInstructions for a broker?
Thanks
Hi Daniel,
our OMS gives priority to tag 21; tag 58 is a “Free format text string” in which, if Care Order, it’s possible put some instructions. in case of DMA, our clients could write in it other infos (maybe related to settlement).
Summarizing, NOS with 58= is not necessarily a Care Order…
Hi Lanfranco,
Text 58 has no FIX value and as you pointed out is a “Free format text string” for display purposes for human consumption. It could be used by a FIX tester / FIX Engine server administrator who is tailing a FIX log in command prompt and viewing only lines which have the string ^58= (where ^ is FIX Tag SOH delimiter).
If Care Order, is it a human operator who reads the text and performs some OMS action or does a program parse thru contents of tag 58 text and apply AI / logic and perform some OMS action ? I do not think any automated FIX Session or Object behaviour should depend on contents of tag 58 Text. If automated FIX / OMS action is performed based on 58, is there any publicly available documentation for “Care Order” which describes what is permitted in tag 58 and its corresponding descriprion / interpretation / purpose ?
My thoughts on Tag 58 Text is :- most computer programming languages provide programmers a means to place comments between code for use by themselves later / for the next developer who would inherit the code / as par of software quality documentation requirements. The compiler completely ignores these comments, compiler compiles only the code. Compilers do not look thru comments to interpret what the programmer is trying to do. Comments are for human use. Similarly tag 58 Text is for human use. Views welcome.
Hi Daniel,
My recommendation is to just pass thru contents of Tag 58 Text and perform FIX action based solely on HandlInst (21). If your HandlInst 21 = 2 (Automated execution order, public, Broker intervention OK) or 3 (Manual order, best execution), then Tag 58 Text could be used by BuySide trader to include a verbal instruction to the SellSide trader (replaces a Electronic Text chat message or phone call) but I do not expect any automation based on contents of free format text.
Regards,
K. Mahesh
Hello
How should we implement our FIX engine when a NOS arrives with the 21=1 (DMA) and 58=?Should we route this order directly to the exchange or does the text has priority over the HandlInst since text could be some HandlingInstructions for a broker?
Thanks
Hi Daniel,
our OMS gives priority to tag 21; tag 58 is a “Free format text string” in which, if Care Order, it’s possible put some instructions. in case of DMA, our clients could write in it other infos (maybe related to settlement).
Summarizing, NOS with 58= is not necessarily a Care Order…
Hi Lanfranco,
Text 58 has no FIX value and as you pointed out is a “Free format text string” for display purposes for human consumption. It could be used by a FIX tester / FIX Engine server administrator who is tailing a FIX log in command prompt and viewing only lines which have the string ^58= (where ^ is FIX Tag SOH delimiter).
If Care Order, is it a human operator who reads the text and performs some OMS action or does a program parse thru contents of tag 58 text and apply AI / logic and perform some OMS action ? I do not think any automated FIX Session or Object behaviour should depend on contents of tag 58 Text. If automated FIX / OMS action is performed based on 58, is there any publicly available documentation for “Care Order” which describes what is permitted in tag 58 and its corresponding descriprion / interpretation / purpose ?
My thoughts on Tag 58 Text is :- most computer programming languages provide programmers a means to place comments between code for use by themselves later / for the next developer who would inherit the code / as par of software quality documentation requirements. The compiler completely ignores these comments, compiler compiles only the code. Compilers do not look thru comments to interpret what the programmer is trying to do. Comments are for human use. Similarly tag 58 Text is for human use. Views welcome.
Hi Daniel,
My recommendation is to just pass thru contents of Tag 58 Text and perform FIX action based solely on HandlInst (21). If your HandlInst 21 = 2 (Automated execution order, public, Broker intervention OK) or 3 (Manual order, best execution), then Tag 58 Text could be used by BuySide trader to include a verbal instruction to the SellSide trader (replaces a Electronic Text chat message or phone call) but I do not expect any automation based on contents of free format text.
Regards,
K. MaheshHello
How should we implement our FIX engine when a NOS arrives with the 21=1 (DMA) and 58=?Should we route this order directly to the exchange or does the text has priority over the HandlInst since text could be some HandlingInstructions for a broker?
Thanks
Hi Daniel,
our OMS gives priority to tag 21; tag 58 is a “Free format text string” in which, if Care Order, it’s possible put some instructions. in case of DMA, our clients could write in it other infos (maybe related to settlement).
Summarizing, NOS with 58= is not necessarily a Care Order…
I totally agree with you, Kay.
I never heard about of specification about an automation purpose on tag 58…
We defined a custom tag (XML) in which our OMS reads instructions for auto Care Order Handling (similar to FixATDL); tag 58 is displayed in the blotter as “Memo” field: only for human! 
Regards,
Lanfranco
[ original email was from Abhay Srivastava - abhay.srivastava@credit-suisse.com ]
Hi Daniel,
Strictly speaking Clients should use Tag 21=1 only for DMA / Algo orders and Tag 21=3 for Care orders.
However, practically many client OMS are not configured in a manner to send different values of Tag 21 for DMA and Desk (Care).
They can specify Care using many tags, common being Tag 1, Tag 57, Tag 58, or even Trader specific like Tag 116.
Its better to give Tag 58 pref over Tag 21, so that client can have more flexibility and your system is capable to accomodate varied cleint request.
-Abhay
Hi Lanfranco,
Text 58 has no FIX value and as you pointed out is a “Free format text string” for display purposes for human consumption. It could be used by a FIX tester / FIX Engine server administrator who is tailing a FIX log in command prompt and viewing only lines which have the string ^58= (where ^ is FIX Tag SOH delimiter).
If Care Order, is it a human operator who reads the text and performs some OMS action or does a program parse thru contents of tag 58 text and apply AI / logic and perform some OMS action ? I do not think any automated FIX Session or Object behaviour should depend on contents of tag 58 Text. If automated FIX / OMS action is performed based on 58, is there any publicly available documentation for “Care Order” which describes what is permitted in tag 58 and its corresponding descriprion / interpretation / purpose ?
My thoughts on Tag 58 Text is :- most computer programming languages provide programmers a means to place comments between code for use by themselves later / for the next developer who would inherit the code / as par of software quality documentation requirements. The compiler completely ignores these comments, compiler compiles only the code. Compilers do not look thru comments to interpret what the programmer is trying to do. Comments are for human use. Similarly tag 58 Text is for human use. Views welcome.
Hi Daniel,
My recommendation is to just pass thru contents of Tag 58 Text and perform FIX action based solely on HandlInst (21). If your HandlInst 21 = 2 (Automated execution order, public, Broker intervention OK) or 3 (Manual order, best execution), then Tag 58 Text could be used by BuySide trader to include a verbal instruction to the SellSide trader (replaces a Electronic Text chat message or phone call) but I do not expect any automation based on contents of free format text.
Regards,
K. MaheshHello
How should we implement our FIX engine when a NOS arrives with the 21=1 (DMA) and 58=?Should we route this order directly to the exchange or does the text has priority over the HandlInst since text could be some HandlingInstructions for a broker?
Thanks
Hi Daniel,
our OMS gives priority to tag 21; tag 58 is a “Free format text string” in which, if Care Order, it’s possible put some instructions. in case of DMA, our clients could write in it other infos (maybe related to settlement).
Summarizing, NOS with 58= is not necessarily a Care Order…I totally agree with you, Kay.
I never heard about of specification about an automation purpose on tag 58…
We defined a custom tag (XML) in which our OMS reads instructions for auto Care Order Handling (similar to FixATDL); tag 58 is displayed in the blotter as “Memo” field: only for human!Regards,
Lanfranco
Hi Abhay,
In my experience with FIXProtocol since Feb-2004, I have never come across / heard of any FIX Engine / Trading Application processing Tag 58 Text. Contents of Tag 58 Text are only used in GUI as display only text. Instead of using Tag 58 to carry automatable information, I would recommend using XMLData and/or RawData to carry any application specific actionable content or better submit Gap analysis / Proposal to GTC and get FIX message(s) / tag(s) / component(s) / repeating group(s) added to newer versions / service packs.
Regards,
K. Mahesh
Its better to give Tag 58 pref over Tag 21, so that client can have more flexibility and your system is capable to accomodate varied cleint request.
-Abhay
[ original email was from John Greenan - john.greenan@alignment-systems.com ]
"…In my experience with FIXProtocol since Feb-2004, I have never come across / heard of any FIX Engine / Trading Application processing Tag 58 Text. Contents of Tag 58 Text are only used in GUI as display only text…"
Really? I have seen several. There are a considerable number of large global broker dealers that will accept “58=VWAP,now,close” (or similar) as a set of input parameters for an algo implementation.
Why? Well the buy-side OMS may be horrifically out of date or no longer supported.
Wonderful. My question - are the systems with which I worked outdated or are systems which use tag 58 for conveying algorithmic trading information out dated ? Now the “FIX heads” could explain to me why these “considerable number of large global broker dealers that will accept “58=VWAP,now,close” (or similar) as a set of input parameters for an algo implementation” were not given participation in the Algo working group and thereby the oppurtunity to make their algo public or alternately if these large global broker dealers created algos before FIXAtdl became a standard and failed to upgrade their systems to use Algo trading as defined by FIX or their algos were so secret that they did not want to share their algo parameters with FIX community and thereby they failed to get FIXAtdl to address all their FIX needs?
How about using position delimited TCP strings instead of FIX messaging on TCP? In terms of pure numbers, a fixed length position delimited string could be smaller in length compared to a FIX message with the same content and thereby transmit faster and at the other end will definetly parse faster. In a classical tag=value[SOH] encoding the message is longer because tag= and the SOH char add to length, the parser has to find the next SOH char to know where to “cut the string” & what to discard (using tailoring terms - the SOH neither belongs to the preceding field nor to the succeding field and needs to be discarded after extracting the preceding field). For a fixed length string with position delimited values a cookie cutter approach can be taken to split the string based on a prefixed lengths template and is thus faster.
If everything can be expressed in Tag 58 Text content, then the complete FIX Business / application layer can be replaced with Tag 58 contents and the only application message required would be a 35=U[SOH]
Question : why use FIX ? Flat Cobol strings over TCP can do the job. How about phone and FAX - the age old tried and time tested methods? I heard FIXProtocol / electronic trading is replacing pit / open outcry trading - too bad people are not given the freedom and opportunity to scream their lungs out, its a deep breating exersise and will beat pranayam any time.
I have worked on a project to develop an algorithim to use Complex Event processing to generate orders by parsing news in multiple formats / feeds including RIXML, there were different strategies like :-
sector strategy:- News=“Obama announced considerable tax breaks for green energy development at today’s UN green house gases meeting”, though there was lot of hot air in the meeting because the meeting was held in the windy city, still all green energy sector company stocks are expected to rise. The opposite of green energy is oil company sector and with the recent oil spill in gulf of mexico, the non-green energy sector is not doing good, so sell oil stocks and buy companies developing wind, solar, wave energy etc.
Inverse pair strategy: News=“Research Analyst at Moody’s predicted that Linux+Java technologies would out outbeat Windows.NET technologies in 5 years”, so sell Microsoft and buy Sun/Oracle, RedHat, IBM etc.
Single company : News=“MacDonald lost class action settlement suit brought by its health conscious customers and more cases may follow”, so become bearish on NYSE:MCD stocks.
News=“Google won its intellectual copyrights patent lawsuit againt its competior”, so remove the bearish outlook previously placed on NASDAQ:GOOG when this lawsuit was initially filed.
News=“Google announced development of a new Android based mobile platform”, so buy NASDAQ:GOOG
Now run rebalance on portfolio(s) based on manually set weights, use transaction cost analysis and do mini-max optimization (minimize risk + maximize return) to generate Buy-Sell orders which get sent to a trading application. The management did not disclose to me what traders did with those orders in production, I only had access to Dev and QA (which was like production :-). I received a big thanks + project completion party and many hours of billing money & I was happy. The money helped put food on my dining table, pay for utilities and buy stuff for my family and finally thats all I care about.
Disclaimer notice:- All names of people, places, companies, products etc. and related news examples have only been used as “real life examples” and do not relate to any real news in past, present or future.
“…In my experience with FIXProtocol since Feb-2004, I have never come across / heard of any FIX Engine / Trading Application processing Tag 58 Text. Contents of Tag 58 Text are only used in GUI as display only text…”
Really? I have seen several. There are a considerable number of large global broker dealers that will accept “58=VWAP,now,close” (or similar) as a set of input parameters for an algo implementation.
Why? Well the buy-side OMS may be horrifically out of date or no longer supported.
[ original email was from John Greenan - john.greenan@alignment-systems.com ]
Exercise for the reader: Go ask any large broker dealer if they will accept a CSV value in tag 58 as an algo input parameter set. Several of them will say yes.
Why? They do this because their buy-side clients have an OMS that does not support FixATDL and/or the buy-side don’t want to pay an OMS vendor for their algo module. Or the buy-side OMS vendor have no interest in building one. So whether the broker supports FIXATDL is not the point. All the brokers I know that support 58=CSV also support ATDL. They simply use 58=CSV as another way to gain distribution.
My statement was about the way the world is, not the way it should be.
Wonderful. My question - are the systems with which I worked outdated or are systems which use tag 58 for conveying algorithmic trading information out dated ? Now the “FIX heads” could explain to me why these “considerable number of large global broker dealers that will accept “58=VWAP,now,close” (or similar) as a set of input parameters for an algo implementation” were not given participation in the Algo working group and thereby the oppurtunity to make their algo public or alternately if these large global broker dealers created algos before FIXAtdl became a standard and failed to upgrade their systems to use Algo trading as defined by FIX or their algos were so secret that they did not want to share their algo parameters with FIX community and thereby they failed to get FIXAtdl to address all their FIX needs?
How about using position delimited TCP strings instead of FIX messaging on TCP? In terms of pure numbers, a fixed length position delimited string could be smaller in length compared to a FIX message with the same content and thereby transmit faster and at the other end will definetly parse faster. In a classical tag=value[SOH] encoding the message is longer because tag= and the SOH char add to length, the parser has to find the next SOH char to know where to “cut the string” & what to discard (using tailoring terms - the SOH neither belongs to the preceding field nor to the succeding field and needs to be discarded after extracting the preceding field). For a fixed length string with position delimited values a cookie cutter approach can be taken to split the string based on a prefixed lengths template and is thus faster.
If everything can be expressed in Tag 58 Text content, then the complete FIX Business / application layer can be replaced with Tag 58 contents and the only application message required would be a 35=U[SOH]
Question : why use FIX ? Flat Cobol strings over TCP can do the job. How about phone and FAX - the age old tried and time tested methods? I heard FIXProtocol / electronic trading is replacing pit / open outcry trading - too bad people are not given the freedom and opportunity to scream their lungs out, its a deep breating exersise and will beat pranayam any time.
I have worked on a project to develop an algorithim to use Complex Event processing to generate orders by parsing news in multiple formats / feeds including RIXML, there were different strategies like :-
sector strategy:- News=“Obama announced considerable tax breaks for green energy development at today’s UN green house gases meeting”, though there was lot of hot air in the meeting because the meeting was held in the windy city, still all green energy sector company stocks are expected to rise. The opposite of green energy is oil company sector and with the recent oil spill in gulf of mexico, the non-green energy sector is not doing good, so sell oil stocks and buy companies developing wind, solar, wave energy etc.
Inverse pair strategy: News=“Research Analyst at Moody’s predicted that Linux+Java technologies would out outbeat Windows.NET technologies in 5 years”, so sell Microsoft and buy Sun/Oracle, RedHat, IBM etc.
Single company : News=“MacDonald lost class action settlement suit brought by its health conscious customers and more cases may follow”, so become bearish on NYSE:MCD stocks.
News=“Google won its intellectual copyrights patent lawsuit againt its competior”, so remove the bearish outlook previously placed on NASDAQ:GOOG when this lawsuit was initially filed.
News=“Google announced development of a new Android based mobile platform”, so buy NASDAQ:GOOG
Now run rebalance on portfolio(s) based on manually set weights, use transaction cost analysis and do mini-max optimization (minimize risk + maximize return) to generate Buy-Sell orders which get sent to a trading application. The management did not disclose to me what traders did with those orders in production, I only had access to Dev and QA (which was like production :-). I received a big thanks + project completion party and many hours of billing money & I was happy. The money helped put food on my dining table, pay for utilities and buy stuff for my family and finally thats all I care about.
Disclaimer notice:- All names of people, places, companies, products etc. and related news examples have only been used as “real life examples” and do not relate to any real news in past, present or future.
“…In my experience with FIXProtocol since Feb-2004, I have never come across / heard of any FIX Engine / Trading Application processing Tag 58 Text. Contents of Tag 58 Text are only used in GUI as display only text…”
Really? I have seen several. There are a considerable number of large global broker dealers that will accept “58=VWAP,now,close” (or similar) as a set of input parameters for an algo implementation.
Why? Well the buy-side OMS may be horrifically out of date or no longer supported.
[ original email was from Abhay Srivastava - abhay.srivastava@credit-suisse.com ]
Well said John.
Mahesh,
If the clients wants to send a variation in FIX, which might or might not be standard, we will still make sure our system is flexible enough to accept it.
Remember the rule of the game is not to be strictly FIX compliant, its more to accomodate various requests of clients.
Its simple, if we tell the cleint that their system ( OMS) is not FIX compliant and we cannot accomodate thier request, they will go to next broker.
Exercise for the reader: Go ask any large broker dealer if they will accept a CSV value in tag 58 as an algo input parameter set. Several of them will say yes.
Why? They do this because their buy-side clients have an OMS that does not support FixATDL and/or the buy-side don’t want to pay an OMS vendor for their algo module. Or the buy-side OMS vendor have no interest in building one. So whether the broker supports FIXATDL is not the point. All the brokers I know that support 58=CSV also support ATDL. They simply use 58=CSV as another way to gain distribution.
My statement was about the way the world is, not the way it should be.
Wonderful. My question - are the systems with which I worked outdated or are systems which use tag 58 for conveying algorithmic trading information out dated ? Now the “FIX heads” could explain to me why these “considerable number of large global broker dealers that will accept “58=VWAP,now,close” (or similar) as a set of input parameters for an algo implementation” were not given participation in the Algo working group and thereby the oppurtunity to make their algo public or alternately if these large global broker dealers created algos before FIXAtdl became a standard and failed to upgrade their systems to use Algo trading as defined by FIX or their algos were so secret that they did not want to share their algo parameters with FIX community and thereby they failed to get FIXAtdl to address all their FIX needs?
How about using position delimited TCP strings instead of FIX messaging on TCP? In terms of pure numbers, a fixed length position delimited string could be smaller in length compared to a FIX message with the same content and thereby transmit faster and at the other end will definetly parse faster. In a classical tag=value[SOH] encoding the message is longer because tag= and the SOH char add to length, the parser has to find the next SOH char to know where to “cut the string” & what to discard (using tailoring terms - the SOH neither belongs to the preceding field nor to the succeding field and needs to be discarded after extracting the preceding field). For a fixed length string with position delimited values a cookie cutter approach can be taken to split the string based on a prefixed lengths template and is thus faster.
If everything can be expressed in Tag 58 Text content, then the complete FIX Business / application layer can be replaced with Tag 58 contents and the only application message required would be a 35=U[SOH]
Question : why use FIX ? Flat Cobol strings over TCP can do the job. How about phone and FAX - the age old tried and time tested methods? I heard FIXProtocol / electronic trading is replacing pit / open outcry trading - too bad people are not given the freedom and opportunity to scream their lungs out, its a deep breating exersise and will beat pranayam any time.
I have worked on a project to develop an algorithim to use Complex Event processing to generate orders by parsing news in multiple formats / feeds including RIXML, there were different strategies like :-
sector strategy:- News=“Obama announced considerable tax breaks for green energy development at today’s UN green house gases meeting”, though there was lot of hot air in the meeting because the meeting was held in the windy city, still all green energy sector company stocks are expected to rise. The opposite of green energy is oil company sector and with the recent oil spill in gulf of mexico, the non-green energy sector is not doing good, so sell oil stocks and buy companies developing wind, solar, wave energy etc.
Inverse pair strategy: News=“Research Analyst at Moody’s predicted that Linux+Java technologies would out outbeat Windows.NET technologies in 5 years”, so sell Microsoft and buy Sun/Oracle, RedHat, IBM etc.
Single company : News=“MacDonald lost class action settlement suit brought by its health conscious customers and more cases may follow”, so become bearish on NYSE:MCD stocks.
News=“Google won its intellectual copyrights patent lawsuit againt its competior”, so remove the bearish outlook previously placed on NASDAQ:GOOG when this lawsuit was initially filed.
News=“Google announced development of a new Android based mobile platform”, so buy NASDAQ:GOOG
Now run rebalance on portfolio(s) based on manually set weights, use transaction cost analysis and do mini-max optimization (minimize risk + maximize return) to generate Buy-Sell orders which get sent to a trading application. The management did not disclose to me what traders did with those orders in production, I only had access to Dev and QA (which was like production :-). I received a big thanks + project completion party and many hours of billing money & I was happy. The money helped put food on my dining table, pay for utilities and buy stuff for my family and finally thats all I care about.
Disclaimer notice:- All names of people, places, companies, products etc. and related news examples have only been used as “real life examples” and do not relate to any real news in past, present or future.
“…In my experience with FIXProtocol since Feb-2004, I have never come across / heard of any FIX Engine / Trading Application processing Tag 58 Text. Contents of Tag 58 Text are only used in GUI as display only text…”
Really? I have seen several. There are a considerable number of large global broker dealers that will accept “58=VWAP,now,close” (or similar) as a set of input parameters for an algo implementation.
Why? Well the buy-side OMS may be horrifically out of date or no longer supported.
Hi Abhay,
My point was not about “how to satisfy clients”, it was about which solution is technically better. Satisfying clients / project managers I always do only within office where salary comes, in FIX discussion forums, I am always bothered only about which solution is better for the longterm growth of FIXProtocol itself and for all its users.
When I worked for a buy side client, I have seen tag 58 sometimes populated with TWAP or VWAP values. but the testcases never included behaviour based TWAP / VWAP values. For example for limit orders the following were the test cases
- Limit Buy Order, Average price after every execution is within Limit price - Execution(s) accepted.
- Limit Buy Order, Average price after every execution breaches limit price by less than 5% - Execution(s) accepted.
- Limit Buy Order, Average price after every execution breaches limit price by more than than 5% - Execution(s) rejected with DKT.
Similar three cases for Sell. In these Limit order tests, average price value is one of the verification fields. The team were told by the project manager - no need for any tests to check the difference between executions when
- Tag 58 is absent
- Tag 58 contains one of the standard values like VWAP, TWAP etc.
- Tag 58 contains some invalid text.
His point was Tag 58 text is not a FIX field to contain any business data, so we shall not have any check on how Tag 58 affects Executions.
Regards,
K. Mahesh
Well said John.
Mahesh,
If the clients wants to send a variation in FIX, which might or might not be standard, we will still make sure our system is flexible enough to accept it.
Remember the rule of the game is not to be strictly FIX compliant, its more to accomodate various requests of clients.
Its simple, if we tell the cleint that their system ( OMS) is not FIX compliant and we cannot accomodate thier request, they will go to next broker.Exercise for the reader: Go ask any large broker dealer if they will accept a CSV value in tag 58 as an algo input parameter set. Several of them will say yes.
Why? They do this because their buy-side clients have an OMS that does not support FixATDL and/or the buy-side don’t want to pay an OMS vendor for their algo module. Or the buy-side OMS vendor have no interest in building one. So whether the broker supports FIXATDL is not the point. All the brokers I know that support 58=CSV also support ATDL. They simply use 58=CSV as another way to gain distribution.
My statement was about the way the world is, not the way it should be.
Wonderful. My question - are the systems with which I worked outdated or are systems which use tag 58 for conveying algorithmic trading information out dated ? Now the “FIX heads” could explain to me why these “considerable number of large global broker dealers that will accept “58=VWAP,now,close” (or similar) as a set of input parameters for an algo implementation” were not given participation in the Algo working group and thereby the oppurtunity to make their algo public or alternately if these large global broker dealers created algos before FIXAtdl became a standard and failed to upgrade their systems to use Algo trading as defined by FIX or their algos were so secret that they did not want to share their algo parameters with FIX community and thereby they failed to get FIXAtdl to address all their FIX needs?
How about using position delimited TCP strings instead of FIX messaging on TCP? In terms of pure numbers, a fixed length position delimited string could be smaller in length compared to a FIX message with the same content and thereby transmit faster and at the other end will definetly parse faster. In a classical tag=value[SOH] encoding the message is longer because tag= and the SOH char add to length, the parser has to find the next SOH char to know where to “cut the string” & what to discard (using tailoring terms - the SOH neither belongs to the preceding field nor to the succeding field and needs to be discarded after extracting the preceding field). For a fixed length string with position delimited values a cookie cutter approach can be taken to split the string based on a prefixed lengths template and is thus faster.
If everything can be expressed in Tag 58 Text content, then the complete FIX Business / application layer can be replaced with Tag 58 contents and the only application message required would be a 35=U[SOH]
Question : why use FIX ? Flat Cobol strings over TCP can do the job. How about phone and FAX - the age old tried and time tested methods? I heard FIXProtocol / electronic trading is replacing pit / open outcry trading - too bad people are not given the freedom and opportunity to scream their lungs out, its a deep breating exersise and will beat pranayam any time.
I have worked on a project to develop an algorithim to use Complex Event processing to generate orders by parsing news in multiple formats / feeds including RIXML, there were different strategies like :-
sector strategy:- News=“Obama announced considerable tax breaks for green energy development at today’s UN green house gases meeting”, though there was lot of hot air in the meeting because the meeting was held in the windy city, still all green energy sector company stocks are expected to rise. The opposite of green energy is oil company sector and with the recent oil spill in gulf of mexico, the non-green energy sector is not doing good, so sell oil stocks and buy companies developing wind, solar, wave energy etc.
Inverse pair strategy: News=“Research Analyst at Moody’s predicted that Linux+Java technologies would out outbeat Windows.NET technologies in 5 years”, so sell Microsoft and buy Sun/Oracle, RedHat, IBM etc.
Single company : News=“MacDonald lost class action settlement suit brought by its health conscious customers and more cases may follow”, so become bearish on NYSE:MCD stocks.
News=“Google won its intellectual copyrights patent lawsuit againt its competior”, so remove the bearish outlook previously placed on NASDAQ:GOOG when this lawsuit was initially filed.
News=“Google announced development of a new Android based mobile platform”, so buy NASDAQ:GOOG
Now run rebalance on portfolio(s) based on manually set weights, use transaction cost analysis and do mini-max optimization (minimize risk + maximize return) to generate Buy-Sell orders which get sent to a trading application. The management did not disclose to me what traders did with those orders in production, I only had access to Dev and QA (which was like production :-). I received a big thanks + project completion party and many hours of billing money & I was happy. The money helped put food on my dining table, pay for utilities and buy stuff for my family and finally thats all I care about.
Disclaimer notice:- All names of people, places, companies, products etc. and related news examples have only been used as “real life examples” and do not relate to any real news in past, present or future.
“…In my experience with FIXProtocol since Feb-2004, I have never come across / heard of any FIX Engine / Trading Application processing Tag 58 Text. Contents of Tag 58 Text are only used in GUI as display only text…”
Really? I have seen several. There are a considerable number of large global broker dealers that will accept “58=VWAP,now,close” (or similar) as a set of input parameters for an algo implementation.
Why? Well the buy-side OMS may be horrifically out of date or no longer supported.
Hello
How should we implement our FIX engine when a NOS arrives with the 21=1 (DMA) and 58=?Should we route this order directly to the exchange or does the text has priority over the HandlInst since text could be some HandlingInstructions for a broker?
Thanks
Some of the answers in this thread seem to miss the point of having different handling instructions.
21=1 should be a low-touch, minimum service to your clients (direct to exchange, no broker intervention) whereas 21=2 or 21=3 are high-touch, worked orders for best execution.
Ignoring tag 58 (which I agree is for human consumption only) for 21=1 makes sense if you’re trying to propose separate order execution services.
Jonathan
A 21=1 order is a DMA order i.e. direct market access order. The only condition checked at the fix level is that the respective user id is logged based on the account id mapping. If the condition is satisfied then the order is directly routed to the exchange automatically.
Thanks
Sudhir
Hello
How should we implement our FIX engine when a NOS arrives with the 21=1 (DMA) and 58=?Should we route this order directly to the exchange or does the text has priority over the HandlInst since text could be some HandlingInstructions for a broker?
Thanks