[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

MTF minutes June 27 2008



Attendees
========
Robert S., Brookpath
Andrew J, Handcoded
Irina Y, ISDA
Lyteck L, ISDA
Marc G., ISDA
Brian L, GEM
Jason P, BGI

Regrets
======
Christian N., Message Automation
Matthew R., JPM

Status of actions
=================
Andrew circulated an updated diagram of key FpML entities
Marc circulated a set of usage scenarios for his identification proposal
based on Christian's document.
Brian updated the Standards Committee presentation


FpML Entities diagram
=====================
We discussed this diagram for several minutes.  We agreed that it did a good
job of representing the relationships between the key FpML entities.  It
does not really cover roles outside of the current trade representation
(such as settlement roles) as these are not well defined in FpML.

We agreed that we would need the products to be able to reference the
accounts belonging to the payer and receiver parties.
We agreed that most of the additional role information belongs outside of
the trade, but also outside of the parties and accounts.
Brian suggested that we need a new structure or structures capable of
representing the relationship of parties with each other and even of
accounts with each other.  This might, for instance, take the form of a
settlement instruction ("pay this account from that account").

Robert volunteered to take another crack at producing some examples of these
types of relationships, this time outside of the trade/account structure.

Identification
==============
Marc presented his scenarios.

We agreed with his proposal that the correlation object reference be
directly to the primary identifier, rather than to the parent structure, to
be more explicit and more consistent with previous FpML versions.

Marc commented that the existing effective date on the versioned trade
identifier seemed to cover much the same purpose as the timestamp that the
identification requirements specify.  He volunteered to look into the
definition of this element and see if the two could be rationalized.

The group like Marc's proposal in combination with Christian's.

Stds Committee Presentation
===========================
We reviewed the presentation to the standards committee.  There were some
corrections noted to the identification area, but otherwise no changes.  The
group was satisfied with the presentation.

Issues
======
We discussed a number of the issues:

#358  - date reference - Marc will look at it, but expects that it will
require some modeling changes to meet the ecore limitations.  Marc will come
back to the group with the issues more clearly delineated.
#511 - causal order design assumption.  We rejected this proposal on the
grounds that a recipient can only know the order that messages actually
arrive.  Brian will draft language around this. (see below).

On the causal order design assumption:

The MTF holds that implementers are responsible for processing messages in
the order that they are received, and not for reordering messages to their
presumed order of creation.  The FpML Message processing documentation
guidelines should specify that messages that are known to be received out of
sequence (such as messages that contain an older version number of a given
trade than the most recently processed one) shall be rejected.

We deferred discussion on the other issues due to time limitations.