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.