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
We propose that the tradeHeader be enhanced to allow institutions to record more information about trades, as follows: – add an optional tradeStatus element, of (the existing)type TradeStatusValue. This will allow an FpML user to record the current status of a trade, e.g. in a trade repository or report. – add an optional “description” element, … Continued
At JPM we have been pulling together some feedback on FpML v4-0. We are still awaiting feedback on many areas, however the first set of feedback is listed in the attached document. This feedback mainly concerns the use of Enumerations and Local Element Definitions.