I understand the use of the term ‘equity’ to reflect the historical origin of the products defined in fpml-eqs-4-1.xsd. They came out of the equity market as products and the contribution out of an equity team. My most frequent use of ‘equitySwap’ is for Bond Index TRS and LPI TRS. Neither of which could be … Continued
The additionalData element in MessageRejected is of type xs:string, but has no additionalDataType attribute to identify what it is carrying. This is in contrast to the additionalData element inside ReasonCode, which does have such an attribute. We recommend adding the attribute. Since carrying the source document in this field may be quite a common use … Continued
This is a small issue that came out in usage. Within the download the schema is copied 9 times, once in each sub-directory. For those of my colleagues less experienced with FpML this took some explaining. They checked each file and checked they were identical. I can see this may be necessary to get the … Continued
This is my feedback on implementing the TR: Each .xsd file used to be valid independently. They imported everything they needed to be valid by themselves. Within the 4.0 TR this holds for all files except fpml-msg-4-0.xsd. This file has dependencies on types such as ‘Document’ and ‘Trade’ that are defined in fpml-main-4-0.xsd. The circular … Continued
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 … Continued
Shouldn’t the MessageRejected be defined as a ResponseMessage? The TradeAffirmed message is defined as a ResponseMessage, while the MessageRejected is defined as a NotificationMessage. In a messaging model I think any Message can be Rejected, but the Rejection will always be a response to another message, e.g. TradeAffirmation. In that case one would like to … Continued
The messaging section in the last call working draft is underdocumented, and some parts of it still in the cut and paste form taken from the relevant proposals (viz. “this paper..”). In particular, the Error Handling section lacks detail. The HTML version of the spec has no documentation on the reason elements at all. Guidelines … Continued
I think I discovered an ommission in the TradeCancelled message. The tradeIdentifier and party elements have been assigned inappropriate types (xsd:string) instead of the FpML types. This causes errors while validating a valid TradeCancelled message. Here is the origingal XML code: Am I right or this by design?
My initial feedback on 4.0 LCWD is some of the examples aren’t valid: eqd40_ex06_barrier_knockout_rebate.xml /FpML/trade/equityOption/equityExercise/equityValuation/futuresPriceValuationApp licable This contains an EOL and 9 spaces before the valid value of false. ird_ex02_stub_amort_swap.xml /FpML/trade/swap/swapStream/calculationPeriodDates/firstRegularPeriodStartDate For both swapStreams this contains an EOL and 9 spaces before the valid date. ird_ex05_long_stub_swap.xml /FpML/trade/swap/swapStream/calculationPeriodDates/firstRegularPeriodStartDate Again same problems for both dates. ird_ex06_xccy_swap.xml /FpML/trade/swap/swapStream/cashflows/principalExchange/adjustedPrincipalExchang … Continued
DTCC implemented MessageIDScheme as optional in a product in use by or anticipated to be implemented by many member banks of ISDA. This attribute has been optional in all previous WD versions of the 4.0 FpML that DTCC has studied or implemented. DTCC became aware that the MessageIDScheme was being made mandatory on September 22, … Continued