We’ll have a meeting Wednesdsay as usual.
Next Meeting – Wednesday August 25, 2010 @ 10am New York / 3pm London
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
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
Illustration 1 – Interest Message Exchange – utilizing matching service
Illustration 2 – Interest Message Exchange – not utilizing matching service
Supporting information that explains how the FpML messaging framework can handle the interest process using matching service:
Excerpt from FpML 5.1 section 126.96.36.199 “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:
… Basic message details
… Request specification here
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.