[brusckeabax]

Thanks Irina, I found this link: http://www.fpml.org/spec/fpml-4-4-12-rec-1/html/fpml-4-4-intro.html However, Return Swaps appeared under the number 9 whereas you referred me to section 10. And, this 4.4 is from 2008; a few years ago. I couldn’t find another reference under “Return Swaps Product Archetecture” that seemed more up-to-date. Could you provide a link to the document I should be reading? Thanks so much. Mark

[brusckeabax]

I think I’ve found my answer. I see that the type NonNegativeStep is defined as: “The non-negative rate or amount which becomes effective on the associated stepDate.” I had taken “step” to represent the value of the delta from the previous value. So, if an initial value of 100 declined by 10% per step we would see: -10 -10 -10 … It’s now clear to me that each step represents the value on the corresponding date. So, my example should appear: 90 80 70 … Moreover, it’s now clear why it should be non-negative. The swap should not have negative notionals. (Nor is a negative intrest rate contemplated were a steped schedule represent a series of stepped coupons.)

[brusckeabax]

Thank you very much Irina; you are very kind to reply in such detail. Your response: “…”basket” and its nesting do not make sense within SingleUnderlyer” seems to be the gist of my confusion. I agree; and, probably should have complained about “basket” being mentioned in SingleUnderlyer in my OP. My task is to transliterate FpML into a relational database model. In the relational paradigm it’s costly, painful and confusing to use indirection to excess (trivial concerns in XML). So, I’m looking to wring-out superflous layers of indirection. For my internal relational model I’m tempted to model Underlyer as consiting of either: 1 basket Xor 1 underlyingAsset and 0/1 openUnits 0/1 dividendPayout 0/1 … The effect of my proposed approach would elimonate SingleUnderlyer as a level of indirection. The price I would pay is that I would imply that openUnits, dividendPayout, etc. might be applicable to a basket; which would be incorrect (these optional elements are applicable only to a SingleUdnderlyer). Even so, I can document that this is not intended. Then, I would document that the possibility of an underlyingAsset being a “basket” is ill-advised; instead, the basket element of Underlyer should be used. Do you see any obvious pitfall in this approach – which allows me to wring-out SingleUneerlyer – from my hierarchy? Thanks Mark

[brusckeabax]

Thanks very much Irina, Could you please provide me with at least a partial list of candidates for this Scheme? I’d like to document that this scheme is expected to include things like … May I also suggest that when you know that you are missing a Scheme that you include a proxy document in the repository so that the link is not broken and so that someone looking for the Scheme can know that it’s a known omission and, ideally, where to look for the current status. Such a protocol would make much better use of everyones’ time, both those who are looking in vain and those, like you, who are kind enough to respond to forum inquiries. Thanks, Mark

[brusckeabax]

I’m working on just such an undertaking. It’s a proprietary effort, so I can’t be of much help to you. The little bit I can offer you is that what you propose to do is a very substantial undertaking. I’ve been at it for several weeks now and have at least several weeks to go. You should at least beware of the magnitude of the task ahead of you. Good luck Mark

[brusckeabax]

I’m working on just such an undertaking. It’s a proprietary effort, so I can’t be of much help to you. The little bit I can offer you is that what you propose to do is a very substantial undertaking. I’ve been at it for several weeks now and have at least several weeks to go. You should at least beware of the magnitude of the task ahead of you. Good luck Mark

[Author]

Posts