[mgratacos]

Take a look at the latest version of 5.0 to see if you still have the problem. The Master Schema should be a valid schema by itself and it contains all elements available for all views so it’s not a subset of the views. It’s a superset. I’d recommend to extend from each view (reporting, confirmation or both) instead of doing it from the Master.

[mgratacos]

Compounding in FpML is not expressed using a flag or something similar. It’s just expressed as a calculation frequency higher than the payment frequency (e.g., calculation quarterly (3 M) and payment anual (1 Y)). The compoundingMethod is only used when there is compounding and a spread so the treatment of the spread in the calculation needs to be clarified. Trying to answer your questions: If calculation period frequency is higher than payment frequency then there is compounding so then: 1) It would be defined by the calculation period. 2) It would be defined by the business day convention of the calculation period. 3) Again, it would be defined by the roll day of the calculation period. Why would you have different data fields to represent the calculation of a period different from the compounding fields to express such calculation? The calculation data fields express the parameters of how compounding, if present, should be calculated. Best Regards, Marc

[mgratacos]

1. You know what party you are so you know your partyId. 2. You need to locate the id attribute of the party block where your partyId is. 3. Is your id attribute equal to transferor/@href, transferee/@href, or remainingParty/@href?

[mgratacos]

You’d probably need to extend FpML to create this product. As you say, the Term Deposits are fixed rate only. A bit “radical” alternative would be to use the swap product with a single swapStream to represent the deposit part with floating interest rate. It’s probably cleaner to create an extension and create the product as needed.

[mgratacos]

The annotation of the firstPeriodStartDate says: “The start date of the calculation period if the date falls before the effective date. It must only be specified if it is not equal to the effective date. This date may be subject to adjustment in accordance with a business day convention.”

[mgratacos]

Hi Vikas, FpML 5.0 implements the concept of views, which means having separate packages for each one of the business process areas. The two views published in the latest version of 5.0 (Working Draft 4) http://www.fpml.org/spec/fpml-5-0-5-wd-4/ are: confirmation and reporting. Pretrade was not published in this latest release since it didn’t have enough review. Take a look at the paper “Master-Schema Technical Paper” available on the page of the 5.0 Working Draft 4 release. The 4.5 IRO products would be identical to the 5.0 confirmation view IRO products. There are some differences such as: the root element of the message, accounts have been moved outside party, and changes on the messaging framework but in terms of product representation, they haven’t changed much. There are some planned changes on the FX products so that’s why you won’t see any FX products in this working draft since some major changes on the FX option products are expected. Hope this helps. Kind Regards, Marc

[mgratacos]

I think that the effective date is part of the exercise component of the swaption. In case of Bermudan swaption, look for the bermudaExercise component (substitutes the exercise element), which contains the bermudaExerciseDates. I think the notice date is not part of the confirmation data so that is why is not represented in FpML. Thanks and Regards, Marc

[mgratacos]

The FpML Specifications say (section 3.1.1) […] Transport The parties must agree on the communications transport used to interconnect their businesses. FpML does not endorse any particular messaging transport for communication. The choice of transport is left to the implementer although in practice we expect only a few to be found suitable. […] Thanks and Regards, Marc

[mgratacos]

Hi, For FX digital barriers, did you look at the fxDigitalOption product? (Section 7.5 http://www.fpml.org/spec/fpml-4-7-1-wd-1/html/index.html) Could you clarify what you mean by FX accruals and FX baskets? Are FX bakets a returns swap on a basket of FX rates? Thanks and Regards, Marc

[mgratacos]

There isn’t much consistency on the market about this, not even on the legal documentation where in most part they are used as synonyms. Trade and transaction are used as synonyms. Most of the ISDA documentation uses transaction but it defines concepts such as trade date as a property of a transaction so they are pretty much equivalent. Intially everything was a trade in FpML but the concept of Contract was introduced to represent trades at the allocation level. This is mainly used for the communication between IM and Custodians. There is a proposal in FpML 5.0 to replace the concept of Contract by Trade again since this distinction is causing confusion in the users of the standard. A deal is used in the syndicated loans market to represent an agreement between the borrower and the other parties.

[mgratacos]

Hi Amit, What do you mean by effective date? Do you mean effective date of the underlying swap OR the start/commencement date of the exercise? What do you mean by notice date? Is this when you send some time of notification message? Regards, Marc

[mgratacos]

Hi Steve, The Contract messages were created exclusively to support the communication between Investment Managers and Custodians. The messages are meant to represent transactions after they have been allocated. There are gaps in the messages so you’ll probably need to extend FpML to be able to cover all messages you need in the system. FpML is aware of the problem in the messaging specification and the Messaging Task Force is currently working on improving it in version 5.0. The plan is that version 5.0 will remove the concept of contract and only trade will be used. Answering your specific questions: 1. You should use the “trade” messages if you are not communicating between investment managers and custodians. 2. Contract will probably be deprecated and replaced in version 5. 3. The messageId element in the message header uniquely identifies each message. 4. As you point out there is a problem in the current spec. In version 4.x you can extend FpML and create you correlation identifier to link the messages or use the conversationId elemet to do the linking. I’d recommend extending it since you’ll be able to enforce its presence in the messages. In version 5, a new correlationId element will be used. I am sure you’ll have additional questions. Happy to help. Kind regards, Marc

[mgratacos]

Hi 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

[mgratacos]

No support for rate fixing at the moment. You’d need to create an extension to support it. Regards, Marc

[mgratacos]

Hi, No, you should populate both the exchangeId (primary exchange) and the relatedExchangeId (other exchanges) within the same underlyer: … NSE NSE2 … Hope this helps. Best Regards, Marc

[Author]

Posts