Imported from previous forum
[ original email was from Christopher Lees - christopher.lees@hsbcib.com ]
Absent a centralised matching system for broker to broker confirmation (such as Omgeo MarketMatch), I am assumimg that one party should adopt the “client role” in the FIX confirmation flow (i.e. responding using Confirmation_Ack) rather than requiring double confirmations.
Is there any market convention for which party adopts the “client” role (ie submits Confirmation_Ack message) in broker to broker confirmations?
Certainly,in the UK,and under LSE rules,in a matched transaction,the seller is liable to report and ,therefore,one would assume the duty to send a confirmation falls on the seller.Obviously,many compliance people insist on EVERYTHING being confirmed,irrespective of obligation.
Absent a centralised matching system for broker to broker confirmation
(such as Omgeo MarketMatch), I am assumimg that one party should adopt
the “client role” in the FIX confirmation flow (i.e. responding using
Confirmation_Ack) rather than requiring double confirmations.Is there any market convention for which party adopts the “client” role
(ie submits Confirmation_Ack message) in broker to broker confirmations?
[ original email was from Christopher Lees - christopher.lees@hsbcib.com ]
Sure, the LSE rules imply that the seller should trade report to the exchange by default (unless one of the parties is a registered Market Maker in the stock. In the post-trade space (and on a global basis) no exchange rules will apply and the community is more free to define its own rules.
The real issue here is that for broker to client trades, the broker will code their systems to always send out the ‘Confirmation’ message and receive the ‘Confirmation Ack’. In the broker-to-broker scenario, the broker should (ideally) code their systems to either submit a ‘Confirmation’ OR to respond with a ‘Confirmation Ack’ (i.e. play the client role in the trade). There is a very large incentive for brokers to simply code the ‘Confirmation’ message in the knowledge that it will satisfy their buy-side clients, and bullishly demand that broker counterparts receive their ‘Confirmation’. But then you get two brokers with this attitude, and the whole model collapses as duplicate comfirms start flying.
Unless a clear, global market practise can be established for broker-to-broker transactions early on, I fear that FIX confirms simply won’t be used in this space.
Certainly,in the UK,and under LSE rules,in a matched transaction,the
seller is liable to report and ,therefore,one would assume the duty to
send a confirmation falls on the seller.Obviously,many compliance
people insist on EVERYTHING being confirmed,irrespective of
obligation.
Absent a centralised matching system for broker to broker
confirmation (such as Omgeo MarketMatch), I am assumimg that one party
should adopt the “client role” in the FIX confirmation flow (i.e.
responding using Confirmation_Ack) rather than requiring double
confirmations.Is there any market convention for which party adopts the “client”
role (ie submits Confirmation_Ack message) in broker to broker
confirmations?
[ original email was from Zul Kagalwalla - zkagalwalla@fmco.com ]
Just a thought one side has to a buyer and another has to be a seller.
So I would think the buyer would send confirm on Buy and ACK the SELL
Similarly the sell side would send confirm on Sell and ACK the buy.
Is that acceptable practice.
Sure, the LSE rules imply that the seller should trade report to the
exchange by default (unless one of the parties is a registered Market
Maker in the stock. In the post-trade space (and on a global basis) no
exchange rules will apply and the community is more free to define its
own rules.The real issue here is that for broker to client trades, the broker will
code their systems to always send out the ‘Confirmation’ message and
receive the ‘Confirmation Ack’. In the broker-to-broker scenario, the
broker should (ideally) code their systems to either submit a
‘Confirmation’ OR to respond with a ‘Confirmation Ack’ (i.e. play the
client role in the trade). There is a very large incentive for brokers
to simply code the ‘Confirmation’ message in the knowledge that it will
satisfy their buy-side clients, and bullishly demand that broker
counterparts receive their ‘Confirmation’. But then you get two brokers
with this attitude, and the whole model collapses as duplicate comfirms
start flying.Unless a clear, global market practise can be established for broker-to-
broker transactions early on, I fear that FIX confirms simply won’t be
used in this space.Certainly,in the UK,and under LSE rules,in a matched transaction,the
seller is liable to report and ,therefore,one would assume the duty
to send a confirmation falls on the seller.Obviously,many compliance
people insist on EVERYTHING being confirmed,irrespective of
obligation.Absent a centralised matching system for broker to broker
confirmation (such as Omgeo MarketMatch), I am assumimg that one
party should adopt the “client role” in the FIX confirmation flow
(i.e. responding using Confirmation_Ack) rather than requiring
double confirmations.Is there any market convention for which party adopts the “client”
role (ie submits Confirmation_Ack message) in broker to broker
confirmations?
[ original email was from Christopher Lees - christopher.lees@hsbcib.com ]
This is - of course - one option, although it is somewhat inefficient as in every trade you have one buyer and one seller, and therefore each will generate ‘Confirmation’ messages, and each will Ack the others confirm, so you end up with two confirms for a single trade. This may cause confusion if the confirmation system is linked to other internal systems - the banks trading system knows one trade, the allocation system knows one trade, the settlement interface knows one trade,…, but the confirmation system knows two.
Worse still, what happens if the buyer sends a Confirmation which is Ack’ed by the seller, but the buyer denies the sellers Confirmation (possibly because he suspects it is a duplicate)?? For the same trade we now have a conflicting confirmation status.
Just a thought one side has to a buyer and another has to be a seller.
So I would think the buyer would send confirm on Buy and ACK the SELL
Similarly the sell side would send confirm on Sell and ACK the buy.
Is that acceptable practice.
Sure, the LSE rules imply that the seller should trade report to the
exchange by default (unless one of the parties is a registered Market
Maker in the stock. In the post-trade space (and on a global basis) no
exchange rules will apply and the community is more free to define its
own rules.The real issue here is that for broker to client trades, the broker
will code their systems to always send out the ‘Confirmation’ message
and receive the ‘Confirmation Ack’. In the broker-to-broker scenario,
the broker should (ideally) code their systems to either submit a
‘Confirmation’ OR to respond with a ‘Confirmation Ack’ (i.e. play the
client role in the trade). There is a very large incentive for brokers
to simply code the ‘Confirmation’ message in the knowledge that it
will satisfy their buy-side clients, and bullishly demand that broker
counterparts receive their ‘Confirmation’. But then you get two
brokers with this attitude, and the whole model collapses as duplicate
comfirms start flying.Unless a clear, global market practise can be established for broker-to-
broker transactions early on, I fear that FIX confirms simply won’t be
used in this space.Certainly,in the UK,and under LSE rules,in a matched
transaction,the seller is liable to report and ,therefore,one
would assume the duty to send a confirmation falls on the
seller.Obviously,many compliance people insist on EVERYTHING being
confirmed,irrespective of obligation.Absent a centralised matching system for broker to broker
confirmation (such as Omgeo MarketMatch), I am assumimg that one
party should adopt the “client role” in the FIX confirmation flow
(i.e. responding using Confirmation_Ack) rather than requiring
double confirmations.Is there any market convention for which party adopts the “client”
role (ie submits Confirmation_Ack message) in broker to broker
confirmations?
[ original email was from Zul Kagalwalla - zkagalwalla@fmco.com ]
Set up an agreement:
If I am the buyer I send confirms and you ack.
If I am the seller you send confirms and I ack.
What about it?
This is - of course - one option, although it is somewhat inefficient as
in every trade you have one buyer and one seller, and therefore each
will generate ‘Confirmation’ messages, and each will Ack the others
confirm, so you end up with two confirms for a single trade. This may
cause confusion if the confirmation system is linked to other internal
systems - the banks trading system knows one trade, the allocation
system knows one trade, the settlement interface knows one trade,…,
but the confirmation system knows two.Worse still, what happens if the buyer sends a Confirmation which is
Ack’ed by the seller, but the buyer denies the sellers Confirmation
(possibly because he suspects it is a duplicate)?? For the same trade we
now have a conflicting confirmation status.Just a thought one side has to a buyer and another has to be a seller.
So I would think the buyer would send confirm on Buy and ACK the SELL
Similarly the sell side would send confirm on Sell and ACK the buy.
Is that acceptable practice.
Sure, the LSE rules imply that the seller should trade report to the
exchange by default (unless one of the parties is a registered
Market Maker in the stock. In the post-trade space (and on a global
basis) no exchange rules will apply and the community is more free
to define its own rules.The real issue here is that for broker to client trades, the broker
will code their systems to always send out the ‘Confirmation’
message and receive the ‘Confirmation Ack’. In the broker-to-broker
scenario, the broker should (ideally) code their systems to either
submit a ‘Confirmation’ OR to respond with a ‘Confirmation Ack’
(i.e. play the client role in the trade). There is a very large
incentive for brokers to simply code the ‘Confirmation’ message in
the knowledge that it will satisfy their buy-side clients, and
bullishly demand that broker counterparts receive their
‘Confirmation’. But then you get two brokers with this attitude, and
the whole model collapses as duplicate comfirms start flying.Unless a clear, global market practise can be established for broker-to-
broker transactions early on, I fear that FIX confirms simply won’t
be used in this space.Certainly,in the UK,and under LSE rules,in a matched
transaction,the seller is liable to report and ,therefore,one
would assume the duty to send a confirmation falls on the
seller.Obviously,many compliance people insist on EVERYTHING
being confirmed,irrespective of obligation.Absent a centralised matching system for broker to broker
confirmation (such as Omgeo MarketMatch), I am assumimg that one
party should adopt the “client role” in the FIX confirmation
flow
(i.e. responding using Confirmation_Ack) rather than requiring
double confirmations.Is there any market convention for which party adopts the
“client” role (ie submits Confirmation_Ack message) in broker to
broker confirmations?
[ original email was from Christopher Lees - christopher.lees@hsbcib.com ]
Agreed - a simplistic responsibility by trading direction seems to be the best way to go. I think that for the sake of clarity, FIX should establish a market convention along these lines for all those adopting 4.4 confirm messaging.
[Whether the confirming responsibility falls on the buyer or seller is perhaps a subjective opinion. My gut feeling though is that if we need to select one, it should probably be the seller who confirms because (a) it sits slightly better with the LSE trade reporting rules, and (b) it seems right that the person selling their goods confirms the price they are expecting for them.]
One further subtlety to iron out however, is the various different types of broker-to-broker confirms. Two brokers meeting at a venue where neither actively approach each other (e.g. an exchange order book) could use our buyer / seller confirms rule. A scenario in which a broker passes an order to a local broker for execution seems to be more aligned to the classic broker / client relationship, and should imply that the local broker always confirms to their broker “client” irrespective of trading direction.
Set up an agreement:
If I am the buyer I send confirms and you ack. If I am the seller you
send confirms and I ack.What about it?
This is - of course - one option, although it is somewhat inefficient
as in every trade you have one buyer and one seller, and therefore
each will generate ‘Confirmation’ messages, and each will Ack the
others confirm, so you end up with two confirms for a single trade.
This may cause confusion if the confirmation system is linked to other
internal systems - the banks trading system knows one trade, the
allocation system knows one trade, the settlement interface knows one
trade,…, but the confirmation system knows two.Worse still, what happens if the buyer sends a Confirmation which is
Ack’ed by the seller, but the buyer denies the sellers Confirmation
(possibly because he suspects it is a duplicate)?? For the same trade
we now have a conflicting confirmation status.Just a thought one side has to a buyer and another has to be a
seller.So I would think the buyer would send confirm on Buy and ACK
the SELLSimilarly the sell side would send confirm on Sell and ACK the buy.
Is that acceptable practice.
Sure, the LSE rules imply that the seller should trade report to
the exchange by default (unless one of the parties is a registered
Market Maker in the stock. In the post-trade space (and on a
global basis) no exchange rules will apply and the community is
more free to define its own rules.The real issue here is that for broker to client trades, the
broker will code their systems to always send out the
‘Confirmation’ message and receive the ‘Confirmation Ack’. In the
broker-to-broker scenario, the broker should (ideally) code their
systems to either submit a ‘Confirmation’ OR to respond with a
‘Confirmation Ack’
(i.e. play the client role in the trade). There is a very large
incentive for brokers to simply code the ‘Confirmation’
message in the knowledge that it will satisfy their buy-side
clients, and bullishly demand that broker counterparts
receive their ‘Confirmation’. But then you get two brokers
with this attitude, and the whole model collapses as
duplicate comfirms start flying.Unless a clear, global market practise can be established for broker-to-
broker transactions early on, I fear that FIX confirms simply
won’t be used in this space.Certainly,in the UK,and under LSE rules,in a matched
transaction,the seller is liable to report and ,therefore,one
would assume the duty to send a confirmation falls on the
seller.Obviously,many compliance people insist on EVERYTHING
being confirmed,irrespective of obligation.Absent a centralised matching system for broker to broker
confirmation (such as Omgeo MarketMatch), I am assumimg that
one party should adopt the “client role” in the FIX
confirmation flow
(i.e. responding using Confirmation_Ack) rather than requiring
double confirmations.Is there any market convention for which party adopts the
“client” role (ie submits Confirmation_Ack message) in broker
to broker confirmations?