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
Attachment:
MTF status 2008-03-14.doc
Description: MS-Word document