FpML Issues Tracker

Summary

It seems that not enough attention has been paid to designing response messages in the initial draft of 4.0. Outlined below are some changes we would like to see in the standard.

We think the message "MessageRejected" is based on the incorrect message type. It is based on NotificationMessage, but this has a header that excludes the tag . In ResponseMessages this tag provides the link back to the message to which the response applies. Without the tag, no such link can be made. The name MessageRejected implies that the message is being sent in response to another message, and therefore it should be based on the ResponseMessage message type. Note, this issue has already been raised as message # 46.

The background to this is that we are designing front-office/back-office communication based on asynchronous notification/response messages. An existing notification/response message pair is TradeAffirmation/TradeAffirmed. But we miss the equivalent response to TradeAffirmed for the negative case of the trade not being affirmed.

Actually we intend to use the messages TradeCreated, TradeAmended, and TradeCancelled as notifications from front-office to back-office, and we need the possibility of positive and negatives responses to these messages. We prefer generically named response messages that can be used for all the above notifications. MessageRejected already exists in the draft FpML 4.0, so we intend to use this so long as the defect mentioned earlier is rectified, and it is extended as described below. For positive responses we propose a new message, MessageAccepted, that would be very similar to TradeAffirmed.

For both the response messages, MessageAccepted and MessageRejected, we suggest two extra tags: would be used to hold the status being returned. In our case we would populate it simply with ACK or NACK, but others may use it to pass a more detailed status. is a tag we need to hold the corresponding back-office Trade Id, either created or referred to during the processing of the original notification message by the back-office. Passing this piece of information back to the front-office is one of the key requirements of the response.

Additionally we would like to see MessageRejected expanded with the addition of complexTypes and . Then MessageAccepted and MessageRejected would have the same basic structure, but MessageRejection containing the extra rejection details in the tag .

Example definitions:

Example Messages: CALY200309241318094444 VIDS200309241318012455 CALYPSO VIDS 2003-09-24T13:18:09 _4584836 INGXXXXX ACK 78671

CALY200309241318094444 VIDS200309241318012455 CALYPSO VIDS 2003-09-24T13:18:09 _4584836 INGXXXXX NACK 102 XXX Invalid bookcode check book code original message id