[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

RE: FpML-BP teleconference 2008-02-13

See attached materials for trade execution message discussion.

Best regards,
Marc

-----Original Message-----
From: bpwg@xxxxxxxx [mailto:bpwg@xxxxxxxx] On Behalf Of Marc Gratacos
Sent: Monday, February 11, 2008 11:18 AM
To: bpwg@xxxxxxxx
Subject: FpML-BP teleconference 2008-02-13
Importance: High


The next BPWG meeting will be Wednesday February 13 from 11:00 to 12:00
New York Time. 

Agenda

1. Portfolio reconciliation
2. Trade Execution Messages (I'll send separate email with materials)
3. AOB


Call details:

US: 1 888 481 3032
UK: 0 800 904 7961
Intl: 1 617 801 9600
Code: 8682747


Kind Regards,
-Marc


************************************************************************
**************************************************
The information contained in either this email and, if applicable, the
attachment, are confidential and are intended only for the recipient.
The contents of either the email or the attachment may not be disclosed
or used by anyone other than the addressee. If you are not the intended
recipient(s), any use, disclosure, copying, or distribution is
prohibited and may be unlawful. If you have received this communication
in error, please notify us by e-mail at isda@xxxxxxxx then delete the
e-mail and all attachments and any copies thereof. This communication is
part of an ISDA process and is not intended for unauthorized use or
distribution.
************************************************************************
**************************************************
--- Begin Message --- 
At today's coordination committee meeting I promised to write up the proposal to add trade execution messages in more detail.

 

I've attached a write-up with diagrams, and a preliminary schema.

 

Note that this write up doesn't contain anything on enhancements to the pre-trade process; I'm working on another short document to discuss the options in that area.

 

Regards,

 

Brian Lynn

Attachment: FpML Trade Execution Messages.doc
Description: FpML Trade Execution Messages.doc

Attachment: fpml-trade-notification.xsd
Description: fpml-trade-notification.xsd


--- End Message ---
--- Begin Message --- 
I tend to agree with the sentiment of having a single model for  
affirmation and confirmation assuming that affirmations and  
confirmations are grounded on the notion of being a negotiation  
protocol in which one party asserts some fact and the other agrees or  
disputes the fact and they iterate until they reach agreement.  
Although I have not seen any tri-lateral affirmation and I have seen  
tri-lateral confirmation (i.e. for novations/assignments). Regardless  
the pattern of interaction - the business process if you will - for  
bi-laterals could be identical with the exception of the actual  
message types required. I am minded on both Andrew Parry's and  
Matthew Rawlings desire for abstract choreography descriptions to  
support such situations.

Comments?

Cheers

Steve T


On 20 Jul 2007, at 19:42, Brian Lynn wrote:

>
> I've attached Andrew's document; in the initial mail in this  
> thread, I was
> talking about Trade Execution notification only, so affirmation  
> didn't enter
> into the diagrams.
>
> My understanding of affirmation is that it is a process in which  
> one side
> asserts the existence of a transaction, and the other one agrees  
> ("affirms"
> it).  So the terminology of "tradeAffirmationRequest" would be an  
> assertion
> by one party to another party that a trade was done, together with  
> a request
> for an "affirmation" of that trade (a response by the other party that
> indeed it was done).
>
> I haven't proposed what exactly "tradeAffirmationDisputed" would  
> contain,
> just that it's needed.  The existing FpML affirmation message model  
> doesn't
> include the capability of querying or disputing.
>
> Following Bob's point, I think it might be better if instead of having
> separate affirmation and confirmation models, we had a single  
> integrated
> model that could accommodate both.  However, every time I make a  
> proposal
> along these lines I tend to get flamed, so I'm not so anxious to  
> write it
> up.  It just seems to generate lots of heat and smoke but not so much
> light...  Also, if affirmation in fact confirms the trades, then  
> don't they
> become contracts?  It would be nice if the folks that came up with the
> contract messages could explain how this is supposed to work.
>
>
> Brian
>
>
> -----Original Message-----
> From: coord@xxxxxxxx [mailto:coord@xxxxxxxx] On Behalf Of
> Harry_MCALLISTER@xxxxxxxxxxxxxx
> Sent: Friday, July 20, 2007 2:27 PM
> To: coord@xxxxxxxx
> Cc: awg@xxxxxxxx; bpwg@xxxxxxxx
> Subject: RE: FpML-BP Re: [fpml-coord] RE: FpML-AWG Trade Execution  
> messages
>
>
> I missed the initial mail in this strand, so don't have the
> schema/diagrams. As a result, I'm not clear on the intended purpose of
> tradeAffirmationRequest[ed], Disputed etc.
>
>    the act of affirmation implies an assertion of fact as construed  
> by the
>    affirming party. Does tradeAffirmationRequest play the role of the
>    initiating assertion, implicitly inviting a counter-assertion?  
> or is it
>    just an invitation to enter the affirmation process (I'm  
> assuming the
>    former)?
>
>    does tradeAffirmationDisputed constitute a counter-assertion  
> i.e. is it
>    a statement about the trade from the PoV of the disputing party,
>    containing their contradictory view of the trade content? Or is  
> it just
>    a notification that they dispute the preceding affirmation, so
>    containing a reference the initiating message (inReplyTo ...),  
> but no
>    trade content?
>
>    what is the reply message in the happy path i.e. where the  
> counterparty
>    agrees with the initial affirmation? who compares the  
> affirmations from
>    each side to determine if they agree?
>
>
> I'm grateful for any guidance offered ...
>
> Best regards,
> Harry
>
>
>
>
>
>
>            Internet
>
>            matthew.d.rawlings@xxxxxxxxxxx
>
>            m
> To
>                                                  bpwg
>
>
> cc
>            Sent by: coord@xxxxxxxx               awg, bpwg, coord
>
>
> Subject
>            20/07/2007 17:51                      RE: FpML-BP Re:
> [fpml-coord] RE: FpML-AWG Trade Execution messages
>
>
>
>
>
>                  Please respond to
>
>                    coord@xxxxxxxx
>
>
>
>
>
>
>
>
>
>
>
>
> You need to add the following:
>
> - tradeAffirmed
> - tradeAffirmedModified / tradeAffirmedCorrected
> - tradeAffirmedCancelled / tradeAffirmedWithdrawn
> - tradeAffirmationDisputed
> - tradeAffirmationDisputedModified / tradeAfirmationCorrected
> - tradeAffirmationDisputedCancelled /  
> tradeAffirmationDisputedWithdrawn
>
>
> The pattern of <event>, <event>Corrected, <event>Withdrawn should  
> be fixed
> consistently within the Architecture document. There is too much  
> variation
> already between Cancelled vs Withdrawn and Moddifed vs Corrected.
>
>
>
> Matthew Rawlings
> +44 7917 596 827
>
>
>  "Brian Lynn"
>  <brian.lynn@xxxxxxxxxxxxxxxxxx
>   
> m>                                                                     
>  To
>  Sent by: bpwg@xxxxxxxx                 <bpwg@xxxxxxxx>,  
> <coord@xxxxxxxx>,
>                                         <awg@xxxxxxxx>
>                                                                        
>   cc
>  20/07/2007 15:37
>                                                                     
> Subject
>                                         RE: FpML-BP Re: [fpml- 
> coord] RE:
>         Please respond to               FpML-AWG Trade Execution  
> messages
>           bpwg@xxxxxxxx
>
>
>
>
>
>
>
>
>
>
>
>
> I'm a little confused about "Affirmation".  I always thought that
> affirmation was part of a confirmation process, working at the  
> contract
> level.  If it's at that trade level, it seems to me that we need to
> distinguish between a mere notification and a request for affirmation.
>
> So I would suggest the following, based in large part on Andrew's doc:
>
> If we wish to notify another stakeholder of the execution of the  
> trade, we
> used the following set of notification messages:
> - tradeExecutionNotification
> - tradeExecutionNotificationCorrected
> - tradeExecutionNotificationCancelled
>
> (These names are long and ugly, but I guess everybody can  
> understand what
> they mean and not get their knickers in a twist.)
>
> If we wish another party to agree that a trade was executed, we use  
> the
> following set of request messages:
> - tradeAffirmationRequest(ed)
> - tradeAffirmationRequestCorrected
> - tradeAffirmationRequestCancelled
>
> To respond to these, the recipient would use one of the following  
> messages
> - tradeAffirmed
> - tradeAffirmationDisputed (with content indicating the reason/ 
> location of
> dispute)
>
> Once an affirmation has been completed, either party could send a
> notification of the affirmation (not of the execution, mind, but  
> rather of
> the affirmation)) using the following messages.
>
> - tradeAffirmationNotification
> - tradeAffirmationNotificationCorrected
> - tradeAffirmationNotificationCancelled
>
> (I'm not sure how the last two messages would be generated in  
> practice, but
> I'm pessimistic enough to assume that they would be required.)
>
>
>
> Does this work?
>
> - Brian
>
>
> -----Original Message-----
> From: bpwg@xxxxxxxx [mailto:bpwg@xxxxxxxx] On Behalf Of Andrew Jacobs
> Sent: Tuesday, July 10, 2007 5:39 PM
> To: coord@xxxxxxxx; awg@xxxxxxxx; bpwg@xxxxxxxx
> Subject: FpML-BP Re: [fpml-coord] RE: FpML-AWG Trade Execution  
> messages
>
>
> I like the use of 'corrected' rather than 'modified' but I
> think for consistency the initial message should have the
> same prefix as the corrected and retracted ones.
>
> We also need to differentiate between messages exchanged
> between participants in the negotiation of a trade
> operation and those subsequently sent to non-participants
> who have an interest in the outcome. I've attached a
> section from the updated messaging architecture document I
> was working on for affirmation as an example.
>
> In the current processed many of the final messages in the
> final confirmation phase of the negotiation are
> notifications rather than responses so that they can be
> distributed to others. I think this is wrong and they
> should just be reponses and a different message type used
> for the notification. This change makes the role of the
> receiver clearer it also means that the notifications
> could contain additional information, like the 'on behalf'
> of indicator.
>
> Andrew
>
> On Tue, 10 Jul 2007 13:31:01 -0400 "Brian Lynn"
> <brian.lynn@xxxxxxxxxxxxxxxxxxx> wrote:
>
>> It might be better if we used more explicit words than
>> "Modified" and
>> "Cancelled" ...  taking part of Andrew's suggestion, how
>> about the
>> following?
>>
>> TradeExecuted
>> TradeExecutionCorrected
>> TradeExecutionRetracted
>>
>> (TradeExecutedCorrected or TradeExecutedModified seems
>> very unwieldy to me.)
>>
>>
>> - Brian
>> -----Original Message-----
>> From: awg@xxxxxxxx [mailto:awg@xxxxxxxx] On Behalf Of
>> Anthony B. Coates
>> (Miley Watts)
>> Sent: Tuesday, July 10, 2007 1:15 PM
>> To: awg@xxxxxxxx; coord@xxxxxxxx; bpwg@xxxxxxxx
>> Subject: Re: FpML-AWG Trade Execution messages
>>
>> I agree with Matthew that the scope implied by the names
>> seemed rather
>> larger than the actual scope of the messages, and that
>> can make things
>> misleading.
>>
>> Cheers, Tony.
>>
>> On Mon, 09 Jul 2007 22:01:36 +0100, Brian Lynn
>> <brian.lynn@xxxxxxxxxxxxxxxxxxx> wrote:
>>
>>> Matthew -
>>>
>>>
>>> I'd considered the names you suggested, they just seemed
>>> really unwieldy
>>> to
>>> me.  But perhaps they are better.
>>>
>>>
>>> On the consistency with the contract messages, these are
>>> intended
>>> specifically for reporting block trade executions, so
>>> this is a different
>>> problem.
>>>
>>>
>>>   _____
>>>
>>> From: awg@xxxxxxxx [mailto:awg@xxxxxxxx] On Behalf Of
>>> Matthew Rawlings
>>> Sent: Monday, July 09, 2007 4:10 PM
>>> To: awg@xxxxxxxx; coord@xxxxxxxx; bpwg@xxxxxxxx
>>> Subject: RE: FpML-AWG Trade Execution messages
>>>
>>>
>>> Feedback:
>>>
>>>
>>> This needs doing, and thanks for making a proposal.
>>>
>>>
>>> "TradeModified" - the problem with the name of the
>>> message is that you
>>> are
>>> not modifying the trade; you are modifying the report of
>>> the trade. Why
>>> not
>>> call it "TradeExecutedModified"? The problem I have seen
>>> is people using
>>> modifications of the report to modify the trade
>>> (economic amendments), in
>>> error.
>>>
>>>
>>> "TradeCancelled" - this has the same problem that it
>>> does not cancel a
>>> trade, but cancels the notification of the trade. Why
>>> not call it
>>> "TradeExecutedCancelled"? The problem I have seen is
>>> people using
>>> cancels of
>>> notification to represent cancels (unwinds,
>>> counter-bookings), in error.
>>>
>>>
>>> How does the TradeExecuted message differ from
>>> TradeAffirmed or
>>> ConfirmQuoteAccepted? All three provide notification of
>>> an execution. Why
>>> not just have one message to notify of execution?
>>>
>>>
>>> Why do these have two parties rather than two trade
>>> sides? Presumably
>>> this
>>> is because this will need to wait until FpML 5.0?
>>>
>>>
>>> To what extent is this process consistent with the
>>> Contract messages?
>>> Most
>>> usage of Trade A2A I have seen has been really messaging
>>> of Contracts
>>> (resultant from allocations).
>>>
>>>
>>> Matthew Rawlings
>>>
>>> +44 791 539 7824
>>>
>>>   _____
>>>
>>> From: awg@xxxxxxxx [mailto:awg@xxxxxxxx] On Behalf Of
>>> Brian Lynn
>>> Sent: 09 July 2007 19:04
>>> To: coord@xxxxxxxx; bpwg@xxxxxxxx; awg@xxxxxxxx
>>> Subject: FpML-AWG Trade Execution messages
>>>
>>>
>>> At today's coordination committee meeting I promised to
>>> write up the
>>> proposal to add trade execution messages in more detail.
>>>
>>>
>>> I've attached a write-up with diagrams, and a
>>> preliminary schema.
>>>
>>>
>>> Note that this write up doesn't contain anything on
>>> enhancements to the
>>> pre-trade process; I'm working on another short document
>>> to discuss the
>>> options in that area.
>>>
>>>
>>> Regards,
>>>
>>>
>>> Brian Lynn
>>>
>>
>>
>>
>> --
>> Anthony B. Coates
>> Senior Partner
>> Miley Watts LLP
>> Experts In Data
>> UK: +44 (20) 8816 7700, US: +1 (239) 344 7700
>> Mobile/Cell: +44 (79) 0543 9026
>> Data standards participant: genericode, ISO 20022 (ISO
>> 15022 XML),
>> UN/CEFACT, MDDL, FpML, UBL.
>> http://www.mileywatts.com/
>>
> ---------------------------------------------------------------------- 
> ------
>
>> ---
>> To unsubscribe: Email majordomo@xxxxxxxx with a blank
>> subject line
>> In the body include the line: unsubscribe awg
>> youremail@address
>> To view archives:
>> http://www.fpml.org/_wgmail/_awgmail/threads.html
>>
>>
> ---------------------------------------------------------------------- 
> ------
>
> ---
>> To unsubscribe: Email majordomo@xxxxxxxx with a blank
>> subject line
>> In the body include the line: unsubscribe coord
>> youremail@address
>> To view archives:
>> http://www.fpml.org/_wgmail/_coordmail/threads.html
>
>
> ---------------------------------------------------------------------- 
> ------
> ---
>
> To unsubscribe: Email majordomo@xxxxxxxx with a blank subject line
> In the body include the line: unsubscribe bpwg youremail@address
> To view archives: http://www.fpml.org/_wgmail/_bpwgmail/threads.html
>
>
>
>
>
>
> This communication is for informational purposes only. It is not  
> intended
> as an offer or solicitation for the purchase or sale of any financial
> instrument or as an official confirmation of any transaction. All  
> market
> prices, data and other information are not warranted as to  
> completeness or
> accuracy and are subject to change without notice. Any comments or
> statements made herein do not necessarily reflect those of JPMorgan  
> Chase &
> Co., its subsidiaries and affiliates. This transmission may contain
> information that is privileged, confidential, legally privileged,  
> and/or
> exempt from disclosure under applicable law. If you are not the  
> intended
> recipient, you are hereby notified that any disclosure, copying,
> distribution, or use of the information contained herein (including  
> any
> reliance thereon) is STRICTLY PROHIBITED. Although this  
> transmission and
> any attachments are believed to be free of any virus or other  
> defect that
> might affect any computer system into which it is received and  
> opened, it
> is the responsibility of the recipient to ensure that it is virus  
> free and
> no responsibility is accepted by JPMorgan Chase & Co., its  
> subsidiaries and
> affiliates, as applicable, for any loss or damage arising in any  
> way from
> its use. If you received this transmission in error, please  
> immediately
> contact the sender and destroy the material in its entirety,  
> whether in
> electronic or hard copy format. Thank you. Please refer to
> http://www.jpmorgan.com/pages/disclosures for disclosures relating  
> to UK
> legal entities.
>
>
> This message and any attachments (the "message") is intended solely  
> for the
> addressees and is confidential.
> If you receive this message in error, please delete it and immediately
> notify the sender. Any use not in accord with
> its purpose, any dissemination or disclosure, either whole or  
> partial, is
> prohibited except formal approval.
> The internet can not guarantee the integrity of this message.
> BNP PARIBAS (and its subsidiaries) shall (will) not therefore be  
> liable for
> the message if modified.
> Do not print this message unless it is necessary, consider the  
> environment.
>                 ---------------------------------------------
> Ce message et toutes les pieces jointes (ci-apres le "message")  
> sont etablis
> a l'intention exclusive de ses destinataires et sont confidentiels.  
> Si vous
> recevez ce
> message par erreur, merci de le detruire et d'en avertir immediatement
> l'expediteur.
> Toute utilisation de ce message non conforme a sa destination, toute
> diffusion ou toute publication, totale ou partielle, est interdite,  
> sauf
> autorisation expresse.
> L'internet ne permettant pas d'assurer l'integrite de ce message, BNP
> PARIBAS (et ses filiales) decline(nt) toute responsabilite au titre  
> de ce
> message, dans l'hypothese ou il aurait ete modifie.
> N'imprimez ce message que si necessaire, pensez a l'environnement.
> ---------------------------------------------------------------------- 
> ------
> ---
> To unsubscribe: Email majordomo@xxxxxxxx with a blank subject line
> In the body include the line: unsubscribe coord youremail@address
> To view archives: http://www.fpml.org/_wgmail/_coordmail/threads.html
> <Affirmation Example.doc>

-------------------------------------------------------------------------------
To unsubscribe: Email majordomo@xxxxxxxx with a blank subject line
In the body include the line: unsubscribe bpwg youremail@address
To view archives: http://www.fpml.org/_wgmail/_bpwgmail/threads.html

--- End Message ---