Imported from previous forum
Hi there,
I have a quick question.
How could we handle trading password for Koreas tock exchange.
There’s new requirement of KSE that all order sends to KSE must have a trading password. If I’m using FIX 4.0 to receive orders from external client, which field I should use to use to store this piece of information? Or is it possible for external client to pass along this information VIA FIX?
Thanks in advance,
[ original email was from Leigh Thompson - lthompson@sfe.com.au ]
Hi,
I’m not familiar with the KSE, so I hope this information is relevant.
The SFE has a requirement of a TraderID and password to be supplied during the Logon FIX message, utilising <Tag 96> RawData, which is formatted appropriately.
You obviously will need to confirm will the KSE as to whether they use a standard tag (such as <Tag 58 - Free Text>) or a custom tag. It may create a slightly messy situation where all external FIX message received by yourself will need to be amended to contain the password (one would presume you don’t wish to disclose your password to your clients).
It seems an odd situation to require a password for each new order in an already established FIX session, however they may have some business case for doing so.
regards
> Hi there,
> I have a quick question.
>
> How could we handle trading password for Koreas tock exchange.
>
> There’s new requirement of KSE that all order sends to KSE must have a trading password. If I’m using FIX 4.0 to receive orders from external client, which field I should use to use to store this piece of information? Or is it possible for external client to pass along this information VIA FIX?
>
> Thanks in advance,
>
>
[ original email was from Ryan Pierce - rpierce@taltrade.com ]
> The SFE has a requirement of a TraderID and password to be supplied during the Logon FIX message, utilising <Tag 96> RawData, which is formatted appropriately.
I must advise caution with using 96 for this purpose.
Tag 96 is of type “data” which means that it can contain binary values, including the [SOH] delimiter. Given that it can contain an [SOH], FIX engines require that it immediately be preceeded by tag 95 (RawDataLength), that indicates the number of bytes in this field. (This way, when the parser hits an [SOH], it knows by the byte count whether this is the end of the field, or whether the field’s data contains an [SOH].)
So I cannot stress enough that if you use tag 96, you must specify tag 95 immediately before it, and give a correct byte count!
I recall having serious problems with a firm that insisted upon sending some kind of username or password info in 96, but the firm didn’t send 95. (Or alternately, it might have been Signature without SignatureLength; I don’t remember the exact details.) Our FIX parser refused to parse these messages because it needed to know the field length.
> > The SFE has a requirement of a TraderID and password to be supplied during the Logon FIX message, utilising <Tag 96> RawData, which is formatted appropriately.
> I must advise caution with using 96 for this purpose.
>
Note also that Username (tag 553) and Password (tag 554) were added to the Logon message in FIX 4.3 specifically for this purpose. User-defined tags (the p/w one already exists) could be used if you can’t handle FIX 4.3 tags yet.
[ original email was from Leigh Thompson - lthompson@sfe.com.au ]
Just to clarify, the SFE’s implementation of Tag 96 in the logon message is as Ryan has described below, that is, it is preceeded by Tag 95 which contains the length of the raw data, and both are required Tags.
Thanks for pointing that out Ryan.
regards
>
> > The SFE has a requirement of a TraderID and password to be supplied during the Logon FIX message, utilising <Tag 96> RawData, which is formatted appropriately.
>
> I must advise caution with using 96 for this purpose.
>
> Tag 96 is of type “data” which means that it can contain binary values, including the [SOH] delimiter. Given that it can contain an [SOH], FIX engines require that it immediately be preceeded by tag 95 (RawDataLength), that indicates the number of bytes in this field. (This way, when the parser hits an [SOH], it knows by the byte count whether this is the end of the field, or whether the field’s data contains an [SOH].)
>
> So I cannot stress enough that if you use tag 96, you must specify tag 95 immediately before it, and give a correct byte count!
>
> I recall having serious problems with a firm that insisted upon sending some kind of username or password info in 96, but the firm didn’t send 95. (Or alternately, it might have been Signature without SignatureLength; I don’t remember the exact details.) Our FIX parser refused to parse these messages because it needed to know the field length.
>
>