FpML Issues Tracker

Summary

This was something I raised to the CUG some time ago in preperation for the new B to B messages.

The problem is that for ANY message derived from one of the notification messaging types (novation, payment, trade confirmation, etc.) there is the possibility that one of the parties to the trade will be playing mutiple roles.

If a firm choses to trade with themselves, or play more than one role in an assignment (these scenarios are not that rare) - then the FpML messaging will not support providing only a single party element (and thus a single xsd:id), leaving an "impossible to validate" message.

Example: Party "Acme" through PB, have actually booked a trade with themselves. This may be between different internal "accounts" at Acme - but they still reference themselves on the firm level as "Acme".

In order to build this deal, "Acme" must play both the buyer and the seller of protection. In FpML, specifying both the buyer and seller as "Acme" is not an issue (due to the nature of xsd:idref). However, to support those hrefs, "Acme" would need a single ID. Any more than one would result in invalid XML (due to the nature of xsd:id).

This is a problem, since in order to request the confirmation of that trade - one would need to follow the schema rules for RequestMessage:

This makes it impossible to model a deal where both references are the same since this would mean providing two identical xsd:id's. This happens often, especially at a central service provider, where internal "accounts" are not always visible to system, and entities are more commonly identified at the "firm" level.

This also causes a problem if a firm wants to play 2 or more roles in an assignment, since there is a THREE party requirement for Novation messages. If the Remaining Party and Transferor are the same party (which would be the case in the scenario I described above) this rule in NovationRequestMessage would make it impossible to build the message:

this same paradigm carries over into almost all of the messaging notification models, including TradeCashflowsAsserted, TradeConfirmed, etc.

One plausible solution to this is to change the cardinality in these base types to "one or many". Party/Account references should of course be mandatory - however the assumption that there will always be at least 2 "unique" parties on a contract/trade and at least 3 "unique" parties on an assignment is not a concrete presumption.

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