Re: MTF minutes - 2008-03-14

[matthew.d.rawlings@xxxxxxxxxxxx]

I gave the ISO 20022 Confirmation messages proposed by OMGEO as an example of a highly interactive ISO 20022 business process for Marc's paper.

On the call there was an objection because the messages aren't on their website. The original Business Justification is on the ISO 20022 website but there is now no further public information. I went away to find out what happened.

What has happened is that they are now in the process of re-submitting as a joint initiative between SWIFT and OMGEO, which has been extended to listed derivatives. This covers both bi-lateral and tri-lateral match, affirm, and confirm standardization.

We should take this seriously and benchmark our business processes against the submission. Previously analysis of FpML for completeness in these processes (by myself, Andrew, and Marc), resulted in issues 244 and 390 - which remain on the slate.

There is a general issue in the MTF's remit around modelling problems of unobservable completion and other gaps in business process.

Matthew +44 7917596827


----- Original Message -----
From: "Brian Lynn" [brian.lynn@xxxxxxxxxxxxxxxxxxx]
Sent: 03/14/2008 12:45 PM AST
To: <mtf@xxxxxxxx>
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



-----------------------------------------
This communication is for informational purposes only. It is not
intended as an offer or solicitation for the purchase or sale of
any financial instrument or as an official confirmation of any
transaction. All market prices, data and other information are not
warranted as to completeness or accuracy and are subject to change
without notice. Any comments or statements made herein do not
necessarily reflect those of JPMorgan Chase & Co., its subsidiaries
and affiliates.

This transmission may contain information that is privileged,
confidential, legally privileged, and/or exempt from disclosure
under applicable law. If you are not the intended recipient, you
are hereby notified that any disclosure, copying, distribution, or
use of the information contained herein (including any reliance
thereon) is STRICTLY PROHIBITED. Although this transmission and any
attachments are believed to be free of any virus or other defect
that might affect any computer system into which it is received and
opened, it is the responsibility of the recipient to ensure that it
is virus free and no responsibility is accepted by JPMorgan Chase &
Co., its subsidiaries and affiliates, as applicable, for any loss
or damage arising in any way from its use. If you received this
transmission in error, please immediately contact the sender and
destroy the material in its entirety, whether in electronic or hard
copy format. Thank you.

Please refer to http://www.jpmorgan.com/pages/disclosures for
disclosures relating to UK legal entities.