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

RE: FpML-BP Re: [fpml-coord] RE: FpML-AWG Trade Execution messages



I had envisioned that the “tradeAffirmationDisputed” message below would have the ability to DK the trade, but it could perhaps be done as a separate message.

 

Another model that might work is to combine the “affirmation” and “confirmation matching” processes, so that one side can request that a trade (or contract) could be confirmed, while the other could either affirm it or send a mismatch or unmatched message.

 

With all of this I wasn’t setting out to completely revisit the confirmation model, just to fill a gap in our messages.  I do believe that the confirmation/affirmation model has some flaws, but it’s kind of like the third rail – who ever touches it dies...  So I had just as soon stay away.

 

- Brian

 


From: bpwg@xxxxxxxx [mailto:bpwg@xxxxxxxx] On Behalf Of Robert Green
Sent: Friday, July 20, 2007 11:32 AM
To: bpwg@xxxxxxxx
Subject: RE: FpML-BP Re: [fpml-coord] RE: FpML-AWG Trade Execution messages

 


Brian,

In the affirmation process where are you contemplating the DK of an affirmation request?  I'm envisioning:

        request affirmation -> affirmed confirmation details or affirmation request DK

Affirmation confirmation need not be in direct response to a request for affirmation.  It seems fairly normal one side may be using the trade confirmation message process while the response may be an affirmation.  Has this been contemplated?

Best regards,

Bob

______________________________________
Bob Green
Vice President - Systems
Depository Trust & Clearing Corporation
18301 Bermuda Green Dr, Tampa FL 33647


"Brian Lynn" <brian.lynn@xxxxxxxxxxxxxxxxxxx>
Sent by: bpwg@xxxxxxxx

07/20/2007 10:37 AM

Please respond to
bpwg@xxxxxxxx

To

<bpwg@xxxxxxxx>, <coord@xxxxxxxx>, <awg@xxxxxxxx>

cc

 

Subject

RE: FpML-BP Re: [fpml-coord] RE: FpML-AWG Trade Execution messages

 

 

 





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


________________________________________________________
DTCC DISCLAIMER: This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error, please notify us immediately and delete the email and any attachments from your system. The recipient should check this email and any attachments for the presence of viruses. The company accepts no liability for any damage caused by any virus transmitted by this email.