Need to identify legitimate universe of OnBehalfOfCompIDs

, ,
1

Imported from previous forum

2 
There seems to be advantage of identifying a list of valid values used in OnBehalfOfCompIDs / SubIds at the time of LOGON, which will be used when routing business messages.

This would provide an advanced warning (at the time of the logon) if two parties (service provider and its point of access destination) are out of synch.
This would require third party service providers to list those allowed to route to destination, which for recipient would mean configured destinations available through the service provider.
The intention of above is to ensure that a service provider and its point of access are not out of sych. as it relates to destinations configured. When handshake happens each side would list their “expectations” and may be used to prevent rejects based of unknown sources / destinations.
In addition, there can be an indicative flag, which states what field combination will be used (on behalf of / deliver to or sender / target sub ids). This would acknowledge and cater for deviations from the norm.
Monitoring which destinations are actually available would be a different topic.
I will be interested thoughts of my fellows and if there is enough interest to include this in the next service pack.
I thank everybody in advance.
Natan

3

I’m confused by this requirement, because it does not match my understanding of the meaning of tags OnBehalfOfCompIDs / SubIds:
If a Service provider (say firm A) sends FIX messages to point of access/destination (say firm B), and includes in these messages ids of firms (X, Y and Z) on behalf of which it is acting (thus X, Y and Z ids are stored on tags “OnBehalfOfCompIDs”), B does not need to know about connection status of X Y and Z.
B simply returns back to A, in the ExecReports, the relevant “OnBehalf” regardless of who they are and how they are connected. It’s A’s duty to manage X, Y and Z connections and messages. And there should not be any knowledge by B of X, Y and Z…
Anybody agrees with my views?
Benoit Compte
(NYSE Euronext Technology)

    There seems to be advantage of identifying a list of valid
    values used in OnBehalfOfCompIDs / SubIds at the time of LOGON,
    which will be used when routing business messages. This would
    provide an advanced warning (at the time of the logon) if two
    parties (service provider and its point of access destination)
    are out of synch. This would require third party service
    providers to list those allowed to route to destination, which
    for recipient would mean configured destinations available
    through the service provider. The intention of above is to
    ensure that a service provider and its point of access are not
    out of sych. as it relates to destinations configured. When
    handshake happens each side would list their "expectations" and
    may be used to prevent rejects based of unknown sources /
    destinations. In addition, there can be an indicative flag,
    which states what field combination will be used (on behalf of /
    deliver to or sender / target sub ids). This would acknowledge
    and cater for deviations from the norm. Monitoring which
    destinations are actually available would be a different topic.
    I will be interested thoughts of my fellows and if there is
    enough interest to include this in the next service pack. I
    thank everybody in advance. Natan
4

I understood Natan’s suggestion to reflect the “universe” (not status) of counterparties which the hub supports for that FIX session, with the primary objective to detect at Logon cases where the hub might send an ‘unexpected/not configured’ value. I think there is merit in that.

I’m confused by this requirement, because it does not match my
understanding of the meaning of tags OnBehalfOfCompIDs / SubIds: If a
Service provider (say firm A) sends FIX messages to point of
access/destination (say firm B), and includes in these messages ids of
firms (X, Y and Z) on behalf of which it is acting (thus X, Y and Z ids
are stored on tags “OnBehalfOfCompIDs”), B does not need to know about
connection status of X Y and Z. B simply returns back to A, in the
ExecReports, the relevant “OnBehalf” regardless of who they are and how
they are connected. It’s A’s duty to manage X, Y and Z connections and
messages. And there should not be any knowledge by B of X, Y and Z…
Anybody agrees with my views? Benoit Compte (NYSE Euronext Technology)

    There seems to be advantage of identifying a list of valid
    values used in OnBehalfOfCompIDs / SubIds at the time of
    LOGON, which will be used when routing business messages. This
    would provide an advanced warning (at the time of the logon)
    if two parties (service provider and its point of access
    destination) are out of synch. This would require third party
    service providers to list those allowed to route to
    destination, which for recipient would mean configured
    destinations available through the service provider. The
    intention of above is to ensure that a service provider and
    its point of access are not out of sych. as it relates to
    destinations configured. When handshake happens each side
    would list their "expectations" and may be used to prevent
    rejects based of unknown sources / destinations. In addition,
    there can be an indicative flag, which states what field
    combination will be used (on behalf of / deliver to or sender
    / target sub ids). This would acknowledge and cater for
    deviations from the norm. Monitoring which destinations are
    actually available would be a different topic. I will be
    interested thoughts of my fellows and if there is enough
    interest to include this in the next service pack. I thank
    everybody in advance. Natan