Imported from previous forum
Hi,
We are a service provider that routes orders between firms.
Our Order routing sytem(OMS) will reject any order where the intended receiver is NOT considered present. This is easily implemented using our custom rich client application that some firms use. This client application uses a socket connection into our OMS to communicate whether a trader is present or not when the trader is logs in or out.
Many firms are now starting to come through FIX. This presents a problem.
FIX does not provide a mechanism (AFAIK) to know if individual traders on the other side of the FIX gateway are “present”.
I realize this might not fit very well into FIX but I’d like to know how other people in the same situation impelement this ?
all other suggestions are also welcome.
regards
[ original email was from John Prewett - jprewett@lavatrading.com ]
> Hi,
We are a service provider that routes orders between firms.
Our Order routing sytem(OMS) will reject any order where the intended
receiver is NOT considered present. This is easily implemented using our
custom rich client application that some firms use. This client
application uses a socket connection into our OMS to communicate whether
a trader is present or not when the trader is logs in or out.Many firms are now starting to come through FIX. This presents a
problem.FIX does not provide a mechanism (AFAIK) to know if individual traders
on the other side of the FIX gateway are “present”.I realize this might not fit very well into FIX but I’d like to know how
other people in the same situation impelement this ?all other suggestions are also welcome.
regards
You could always use TradingSessionStatus messages to indicate availability of an individual trader. The field TradingSessionID is used to identify the session that status is being reported about. This field is a simple string that can contain any values which “should be bi-laterally agreed between counterparties”. The latter part of the last sentence is a direct quote from the FIX.4.2 specification.
I hope this helps.
JohnP
[ original email was from Nick Serafini - nserafini@mac.com ]
How about TargetSub or something of that nature - Far side includes the targetsub ( desk trader , floor / etc ) to execute the order, your system checks if that TargetSub user’s ID is logged in, if it is, he gets order; If not, reject or reroute -
It becomes a mess when you have 300 possible TargetSub’s , and how the user will select whom will execute the trade -
TargetSubID (Tag = 57, Type: char)
Assigned value used to identify specific individual or unit intended to receive message. ‘ADMIN’ reserved for administrative messages not intended for a specific user.
Hi,
We are a service provider that routes orders between firms.
Our Order routing sytem(OMS) will reject any order where the intended
receiver is NOT considered present. This is easily implemented using
our custom rich client application that some firms use. This client
application uses a socket connection into our OMS to communicate
whether a trader is present or not when the trader is logs in or out.Many firms are now starting to come through FIX. This presents a
problem.FIX does not provide a mechanism (AFAIK) to know if individual traders
on the other side of the FIX gateway are “present”.I realize this might not fit very well into FIX but I’d like to know
how other people in the same situation impelement this ?all other suggestions are also welcome.
regards
You could always use TradingSessionStatus messages to indicate
availability of an individual trader. The field TradingSessionID is used
to identify the session that status is being reported about. This field
is a simple string that can contain any values which “should be bi-
laterally agreed between counterparties”. The latter part of the last
sentence is a direct quote from the FIX.4.2 specification.I hope this helps.
JohnP
you see, ,knowing whether the trader is logged in is at the heart of the problem. We need the counter party to tell us somehow if their trader is logged in. All order messages anyways, include the trader user id (both for sender and receiver) anyways using onBehalfOfSubID and targetSubID.
Before FIX gateway, this was simply done through our rich client application in the form of a socket connection. If they were logged in, they will have a active socket connection and pinging our OMS periodically. If they logged out or their internet connection somehow was disrupted, that socket connection was no longer there and hence they would be considered logged out.
we don’t have this sort of luxary in FIX.
How about TargetSub or something of that nature - Far side includes the
targetsub ( desk trader , floor / etc ) to execute the order, your
system checks if that TargetSub user’s ID is logged in, if it is, he
gets order; If not, reject or reroute -It becomes a mess when you have 300 possible TargetSub’s , and how the
user will select whom will execute the trade -TargetSubID (Tag = 57, Type: char)
Assigned value used to identify specific individual or unit intended to
receive message. ‘ADMIN’ reserved for administrative messages not
intended for a specific user.Hi,
We are a service provider that routes orders between firms.
Our Order routing sytem(OMS) will reject any order where the
intended receiver is NOT considered present. This is easily
implemented using our custom rich client application that some firms
use. This client application uses a socket connection into our OMS
to communicate whether a trader is present or not when the trader is
logs in or out.Many firms are now starting to come through FIX. This presents a
problem.FIX does not provide a mechanism (AFAIK) to know if individual
traders on the other side of the FIX gateway are “present”.I realize this might not fit very well into FIX but I’d like to know
how other people in the same situation impelement this ?all other suggestions are also welcome.
regards
You could always use TradingSessionStatus messages to indicate
availability of an individual trader. The field TradingSessionID is
used to identify the session that status is being reported about. This
field is a simple string that can contain any values which “should be
bi- laterally agreed between counterparties”. The latter part of the
last sentence is a direct quote from the FIX.4.2 specification.I hope this helps.
JohnP
Well, this might work. The counter party firm will send a TradingSessionStatus message from their system to our system indicating a trader is “present”. Our OMS would update its internal trader cache to indicate he is present. From there on any order routed to that trader will not be rejected.
The counter party firm will send another TradingSessionStatus for that trader to indicate that trader not being present at which point our OMS will mark that trader not present.
are you or anyone doing this ?
Hi,
We are a service provider that routes orders between firms.
Our Order routing sytem(OMS) will reject any order where the intended
receiver is NOT considered present. This is easily implemented using
our custom rich client application that some firms use. This client
application uses a socket connection into our OMS to communicate
whether a trader is present or not when the trader is logs in or out.Many firms are now starting to come through FIX. This presents a
problem.FIX does not provide a mechanism (AFAIK) to know if individual traders
on the other side of the FIX gateway are “present”.I realize this might not fit very well into FIX but I’d like to know
how other people in the same situation impelement this ?all other suggestions are also welcome.
regards
You could always use TradingSessionStatus messages to indicate
availability of an individual trader. The field TradingSessionID is used
to identify the session that status is being reported about. This field
is a simple string that can contain any values which “should be bi-
laterally agreed between counterparties”. The latter part of the last
sentence is a direct quote from the FIX.4.2 specification.I hope this helps.
JohnP
FIX 4.4 introduced Network (Counterparty System) Status Request and Network (Counterparty System) Status Response messages. These are documented within Volume 1 of the spec and under “Application Messages: Other” within FIXimate 4.4
Hi,
We are a service provider that routes orders between firms.
Our Order routing sytem(OMS) will reject any order where the intended
receiver is NOT considered present. This is easily implemented using our
custom rich client application that some firms use. This client
application uses a socket connection into our OMS to communicate whether
a trader is present or not when the trader is logs in or out.Many firms are now starting to come through FIX. This presents a
problem.FIX does not provide a mechanism (AFAIK) to know if individual traders
on the other side of the FIX gateway are “present”.I realize this might not fit very well into FIX but I’d like to know how
other people in the same situation impelement this ?all other suggestions are also welcome.
regards
Thanks Scott. I will look over this and see if it is what I need.
FIX 4.4 introduced Network (Counterparty System) Status Request and Network (Counterparty System) Status Response messages. These are documented within Volume 1 of the spec and under “Application Messages: Other” within FIXimate 4.4
Hi,
We are a service provider that routes orders between firms.
Our Order routing sytem(OMS) will reject any order where the intended
receiver is NOT considered present. This is easily implemented using
our custom rich client application that some firms use. This client
application uses a socket connection into our OMS to communicate
whether a trader is present or not when the trader is logs in or out.Many firms are now starting to come through FIX. This presents a
problem.FIX does not provide a mechanism (AFAIK) to know if individual traders
on the other side of the FIX gateway are “present”.I realize this might not fit very well into FIX but I’d like to know
how other people in the same situation impelement this ?all other suggestions are also welcome.
regards
[ original email was from G.Vijay Kumar - evervj.extras@gmail.com ]
Actually i implemented the same scenario in my fix engine which has been used between few of our customer.
Actually we had the custom tag called “SessionStatus” in the heart beat message. Whenever we recive the heart beat message, we will check the sendercompid then we will check for the SessionStatus. If the SessionStatus value is “LoggedOn” then we keep continue the session. Otherwise we will logoff.
Cheers,
G.Vijay.
Hi Vijay,
SenderCompID tells you which firm is considered “LoggedOn” right ? We’d like to know which trader within that firm is “LoggedOn”.
or am I missing something.
maybe you just care about the firm status and assume that and any order destined for a trader in that firm is considered “loggedOn” since firm is considered “loggedOn” ?
thanks.
Actually i implemented the same scenario in my fix engine which has been
used between few of our customer.Actually we had the custom tag called “SessionStatus” in the heart beat
message. Whenever we recive the heart beat message, we will check the
sendercompid then we will check for the SessionStatus. If the
SessionStatus value is “LoggedOn” then we keep continue the session.
Otherwise we will logoff.Cheers,
G.Vijay.
[ original email was from G.Vijay Kumar - evervj.extras@gmail.com ]
Hi Jhon,
yes you are right. But my scenario is bit different i think. Though i dont know about ur architecture i thought something and putting it down.
I am having the assumption.
your OMS is connection to another fix engine. ie it maintain only one fix session with each firm. and each firm has “N” number of traders.
In Fix Header we have the fields
Firm
SenderCompID --> Firm’s SendCompID–>
SenderSubID --> Firm’s Trader ID -->
SenderLocationID
In SenderSubID If u maintain the Trader logon status along with the traderid for example
When ever trader logged on SenderSubID == "TraderID/LogedOn"
When ever trader logged off SenderSubID == “TraderID/Logoff”
you can control the rest in your system ( this is only for fix version <= 4.3 )
thanks
Hi Vijay, thanks for response.
Our OMS has a connection(through messaging middleware) to our Fix gateway. Our Fix gateway has one fix connection to each firm.
What you say makes sense if I underestand correctly. The heartbeats from each firm, carries logon status of their traders. So on every heartbeat from each firm , you check to see if a trader status is changed or toggled( loggedOn/loggedOff) and if so then you update your trader presence cache or persistance store (possibly residing in your OMS somewhere) with that information.
is this correct generally ?
thanks much.
Hi Jhon, yes you are right. But my scenario is bit different i think.
Though i dont know about ur architecture i thought something and
putting it down.I am having the assumption.
your OMS is connection to another fix engine. ie it maintain only one
fix session with each firm. and each firm has “N” number of traders.In Fix Header we have the fields
Firm
SenderCompID → Firm’s SendCompID–> SenderSubID → Firm’s Trader ID
→ SenderLocationIDIn SenderSubID If u maintain the Trader logon status along with the
traderid for exampleWhen ever trader logged on SenderSubID == “TraderID/LogedOn” When ever
trader logged off SenderSubID == “TraderID/Logoff”you can control the rest in your system ( this is only for fix version
<= 4.3 ) thanks