Forums
FpML Discussion
General FpML Discussion › Technical & Implementation Questions › Uniquely identifying FpML confirmations?
- This topic has 2 replies, 2 voices, and was last updated 15 years, 5 months ago by steveshutts.
-
AuthorPosts
-
September 4, 2009 at 4:21 am #1783steveshuttsMember
Is somebody able to explain how a specific confirmation can be uniquely identified within an FpML message? The only examples of FpML messages i have are those posted within the FpML documentation. In the following, i refer to confirmations as these are the types of messages that i am interested in. My understanding is as follows: When an underlying trade is initiated it will receive a tradeId, which is assigned for its entire life cycle. Any subsequent confirmations relating to this trade will contain the same tradeId. Each confirmation message will have its own unique messageId. However, this unique identifier never seems to be used in any subsequent messages. For example, in the case of a Termination message, one needs a mechanism in which to link the Termination confirmation to the underlying trade. The examples provided do not show any unique method of identifying the underlying trade to which the termination applies. The examples also use a conversationId, which seems to be used to link certain confirmations together. One of the examples shows how this is used when a ContractPartialTermination message is corrected. It seems that the current version of FpML does not support amendments for Contract Terminations and therefore there must be some way of linking the messages. The correcting message has the same tradeId and conversationId as the underlying ContractPartialTermination message. Previously, i have dealt largely with SWIFT messages, which use a Related Reference field to identify related confirmations. Most host systems would create a unique Deal Reference for each confirmation. If an amendment was created then this amendment would reference the underlying confirmation. I am now searching for a similar way of uniquely identifying related confirmations but cannot see how this is to be implemented. If anyone could shed some light on this it would be much appreciated. Regards, Steve
September 4, 2009 at 5:46 am #1784mgratacosKeymasterHi Steve, There is currently a problem in FpML regarding this. In FpML 5.0 we are trying to solve this by introducing a new element called correlationId which will be used as a unique identifier for a single business object through its entire life. For example, a partial termination that needs to be created, modified, and cancelled will use the correlationId through its entire process. On the other hand each message will have a unique messageId as you pointed out. In FpML 4.x you could use the existing conversationId to do this correlation and the version of the trade to indicate the sequence of the events. For example, a ContractTermination is created: – sentBy IM – sendTo CUST – messageId IM/1 – conversationId IM/A001 – versionedTradeId/version 1 Let’s say that we need to correct this ContractTermination, then we would send an additional message: – sentBy IM – sendTo CUST – messageId IM/2 – conversationId IM/A001 – versionedTradeId/version 2 Does this make sense? Best Regards, Marc
September 4, 2009 at 8:57 am #1786steveshuttsMemberThanks for quick response Marc, much appreciated. What you have described is how i understand it from the documentation. The use of the conversationId when correcting Contract messages is clear. It just seems a little odd that no unique reference is ever used when amending a trade message i.e. when a ModifyTradeMatch message amends an underlying trade. The only linking identifier is the TradeId, nothing else. When you have multiple confirmations on a system with the same TradeId far more processing is required to correctly identify the confirmation which should be addressed. Steve
-
AuthorPosts
- You must be logged in to reply to this topic.
Search Forums
Recent Topics
-
Repo vs Reverse Repo
2 years, 4 months ago
-
resetFrequency for SOFR OIS
2 years, 9 months ago
-
FXD Option on strategy
3 years ago
-
Forward Exercise
3 years, 3 months ago
-
Usage of IRSwap in Confirmation Process (requestConfirmation)
3 years, 2 months ago