Re: MTF minutes - 2008-03-14

[brian.Lynn@xxxxxxxxxxxxxxxxxxx]

Sorry, Henri.

At least I didn't forget you entirely, like I have others in the past.

Brian

Sent via BlackBerry from T-Mobile

-----Original Message-----
From: Henri Pegeron <hpegeron@xxxxxxxx>

Date: Fri, 14 Mar 2008 16:43:18 
To:mtf@xxxxxxxx
Subject: Re: MTF minutes - 2008-03-14


Hey Brian, 
Slight correction to the agenda: 
 
Henri P, ISDA 
(Not entirely inaccurate - just a little dated heh). 
 
Attendee listing should be: 
 
Henri P, DTCC 
 

 Thanks, Henri
 ------------------------------------------------------------
 The Depository Trust & Clearing Corporation 
 DTCC Deriv/SERV : Business Analysis & Design
 55 Water Street - New York, NY 10041
 Phone: + 1 (212) 855 1682
 Fax: + 1 (212) 855 1020
 
 
 
 
 

 
 
 
 
 
 "Brian Lynn" <brian.lynn@xxxxxxxxxxxxxxxxxxx> 
Sent by: mtf@xxxxxxxx 
03/14/2008 12:45 PM 
 
Please respond to
 mtf@xxxxxxxx 
 
 
To <mtf@xxxxxxxx> 
 
cc 
 
Subject MTF minutes - 2008-03-14 
 
 
 
 
 
Attendees
 ========
 Lyteck L, ISDA
 Irina Y, ISDA
 Henri P, ISDA
 Andrew J, Handcoded
 Andrew P, JPM
 Marc G, ISDA
 Brian L, GEM
 Matthew R, JPM
 Christian N, Message Automation
 
 Apologies
 =========
 Robert S., Brookpath
 Harry McA, BNPP
 
 
 Overall status
 ==============
 We discussed the overall status.  The general status is ok, but we want to
 replace the colour labels with more descriptive state labels (e.g. "Not
 started", "Progressing well", etc.)  See updated version attached.
 
 CDWG Request on Booleans
 ======================
 We briefly reviewed Brian's proposal for answering Ben's questions about how
 to implement the MTF guidelines.  We agreed with Brian's proposal to add
 required Boolean "applicable" elements to structures that require additional
 fields.  We agreed that the Boolean elements that replace the existing
 optional Empty elements must also be optional, to accommodate short forms.
 We agreed that we should ask the CDWG to define business rules for which
 credit events elements should be present for which products in each of short
 and long form.  Brian will update the proposal and send to Ben.
 
 Comparison with other standards
 ===============================
 We discussed Marc's comparison with other standards at length.  
 
 We agreed:
 - we should publish a version of this as a technical note.  Marc will add
 some introductory material.
 - most of the decisions we made in the messaging MTF are supported by the
 comparison with other standards.  This includes decisions on identification,
 on error returns, and on message correlation.
 - in one area we are out of sync:  the modeling of corrections and
 cancellations.  Other standards either use 3 separate messages or 1 with an
 action code.  We propose using 2: one for requests and corrections, and a
 separate one for cancellations.
 - cancellations at the messaging level are not mandatory to be included in
 the standard (at least if we don't define a messaging transport layer), but
 cancellations are necessary at the business level.  I.e. We need to be able
 to cancel a novation confirmation, but not necessarily a message to modify a
 novation confirmation request.
 
 We agreed to hold a vote next meeting on the handling of corrections and
 cancellations.  There are 3 options:
 
 1) retain 4.x approach (3 messages), but add a mechanical way of either
 generating all of the required messages or at least ensuring that all are
 present where necessary.
 2) retain the current 5.x recommendation (2 messages = Request/Correct and
 Cancel), and  be out of sync with other standards  Add a mechanical way of
 ensuring that cancellation messages are present where necessary.
 3) move to a single message with an action/operation code
 (New/Correct/Cancel).  Adjust the schema to allow identifier-only business
 content to support cancellations without full content, and add business
 rules to disallow identifier-only content for the New and Correct cases.
 
 For the voting, I propose the following process:
 a) if one of the choices receives a majority of the votes cast on the
 initial vote, it will be chosen.
 b) otherwise, the choice with the smallest number of votes will be
 eliminated and a new vote will be taken.  Since there will be only 2 choices
 left, it will be simple majority.
 
 In addition, I propose to hold a vote to ratify the recommendation on having
 a single "error" return.  Choices will include: 
 1) retaining the 4.x approach
 2) defining a new processing status message that includes an error
 status/reason code.
 
 Upcoming meetings:
 ==================
 There will be no meeting next week due to the holiday.
 March 28 - 11 AM NY / 3 PM UK - Vote on messaging decisions; discuss
 Matthew's identification validation rules and other identification topics
 April 4 - 11 AM NY / 4 PM UK - agenda TBD
 
 
 
________________________________________________________ 
 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.