From: owner-colwg@xxxxxxxx [mailto:owner-colwg@xxxxxxxx] On Behalf Of richard.barton@xxxxxxxxxxxxxxxx
Sent: Wednesday, August 25, 2010 7:33 AM
To: colwg@xxxxxxxx
Subject: FPML-CWG Collateral WG Meeting: Wed August 25, 2010 @ 10am New York / 3pm London
We’ll have a
meeting Wednesdsay as usual.
Next Meeting –
Wednesday August 25, 2010
@ 10am New York / 3pm
London
Agenda:
We will discuss
the interest
process. Please
review the two options defined within the original ISDA Working Group
Requirements (see illustrations 1 and 2 below). This meeting will discuss
the requirements and determine how to approach them from an FpML
perspective.
·
IN1 – Interest Notification
(<requestInterest>, ex22)
·
IN1 – Interest Notification (matching service)
(<requestInterest>, ex23)
·
IN2/IN3/IN5 – Accept/Reject Date/Dispute
Interest
(<interestStatus>, ex24)
(see schema
& examples attached in zip file / rename .zip-email to
.zip)
Dial in
details:
-
Please join the web
conference
https://www2.gotomeeting.com/join/151660907
Meeting ID:
151-660-907
-
Join the conference
call:
US
Dial-in:
888-481-3032
UK Toll
Free:
0800 904 7961
International Dial-in:
617-801-9600
Passcode:
8682747
Illustration
1 – Interest Message Exchange – utilizing matching
service
Illustration
2 – Interest Message Exchange – not utilizing matching
service
(Ref http://www.isda.org/c_and_a/pdf/Electronic-Messaging.pdf
p.9)
Supporting information that explains
how the FpML messaging framework can handle the interest process using matching
service:
Excerpt from FpML 5.1
section 3.2.12.1 “onBehalfOf”
The FpML neutral view
principle when combined with some of the notifications for post-trade processes
and a common third party such as a custodian results in situations where the
third party can not easily tell which side of the trade he is supposed to be
processing.
For example, parties A and
B negotiate a trade and then send a contract execution notification to their
common custodian C. The custodian may be able to figure out which side of the
trade to process by means of the message sender’s identity but as a single
sender identity might be used by several legally separate trading divisions
within the same company group determining the correct party might require
extensive organisational reference data. This approach would also fail for
internal book-to-book deals where both sides would originate from the same
sender.
What is needed is an
explicit indication of the party for whom the trade should be processed included
in every message. In the case of book-to-book trades this information should use
account references to further qualify the party. For
example:
<someRequest>
<header>
… Basic
message details
</header>
…
<onBehalfOf>
<partyReference href=""/>
<accountReference href=""/>
</onBehalfOf>
… Request
specification here
</someRequest>
Excerpt from FpML 4.9
section 3.2.2 “The Base Message”
…
·
inReplyTo
contains the unique identifier for the request message that is being responded
to.
·
sentBy
identifies the system or party sending a message.
·
sendTo
identifies the systems or parties who will receive a message and should act upon
it.
·
copyTo
identities other systems or parties who will receive a message but who do not
have to act upon it.
Substitution Process – outstanding
question:
·
Do we need to distinguish between
variation margin and segregated independent amount for a
substitution request? The distinction
was originally made for the margin call process and kept in the proposed
substitution messages. This is an open question for the
group.
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
<mailto: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.