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>