Why is Basket in Underlyer?

[brusckeabax]

Underlyer is defined as containing either a: – singleUnderlyer of type SingleUnderlyer Xor – basket of type Basket. Seems reasonable on first impression; but it doesn’t make sense after drilling into SingleUnderlyer. SingleUnderlyer consists of: – 1 mandatory underlyingAsset – several optional incidental elements. underlyingAsset is a “reference”; it’s defined as: I found another FPML XML Schema Document that reads, in part: “Element: underlyingAsset The following elements can be used wherever this element is referenced: – basket – … – simpleSwap” Observe that the first element is “basket” which is of type {Basket}. That is, a “basket” can be an underlyingAsset which can be a SingleUnderlyer. Now, it doesn’t make sense to me that “basket” of type {Basket} is defined as the 2’nd possible content of the generic type Underlyer. (SingleUnderlyer is the 1’st possible content of content of the generic type Underlyer.) What are we to make of FPML’s construct that an Underlyer may consist of either: 1’st – a singleUnderlyer of type {SingleUnderlyer} which could be of type {Basket} Xor, 2’nd – a basket of type {Basket}? My impression is that the distinction between an “Underlyer” vs. a “SingleUnderlier” should be collapsed. That is, an “Underlyer” should consist of: – 1 mandatory underlyingAsset (which might be a {Basket}) – several optional incidental elements. What am I missing? If there is a good reason for this apparent redundancy (basket in both Underlyer and in SingleUnderlyer) I would like to know what that reason is. If there is no current reason, but the authors anticipated some possibility, I’d like to know that possibility. Ultimately, I’d like to know if it’s safe to model (in my internal representation) for Underlying to be composed of the elements of SingleUnderlying and elimonate the intermediate complex type of SingleUnderlying. Thanks Mark

[iyermakova]

Hello Mark, Underlyer – a type describing the whole set of possible underlyers: single underlyers or multiple underlyers, each of these having either security or index components. SingleUnderlyer – Describes the swap’s underlyer when it has only one asset component (bond, commodity, equity, etc). Basket – Describes the swap’s underlyer when it has multiple asset components (basket constituents such as equity, index, convertible bond, or basket components, or some combination of these). BasketConstituent can hold one asset component (e.g. equity see eqcs-ex01-correlation-swap), or another basket (e.g. nested basket see eqd-ex20-nested-basket). People would use a “basket” where they had a reference data system that could lookup basket constituents and weights, rather than state them in each message. Basket and SingleUnderlyer are both Underlyers, the current design (Equity Asset and Basket share a common base class to allow nested baskets) allows you to do all sorts of nesting within “basket” BasketConstituent, but “basket” and its nesting do not make sense within SingleUnderlyer. In the schema, to add an appropriate underlying component, // is an abstract element, a place holder for actual asset component e.g. Or // is an abstract element, a place holder for actual asset component e.g. a “substitution group” mechanism is used. To be a part of the substitution group, underlying asset component should extend UnderlyingAsset abstract type and be itself a part of the “underlyingAsset” substitution group, for instance, or As you see from the above snippets above, since they both are part of the underlying substitution group, in the schema they appear interchangeably as elements that can appear within a BasketConstituent and SingleUnderlyer structures. Therefore, while “equity” component can appear in both structures, the “basket” component appears only in the BasketConstituent structure. Regards, Irina Yermakova

[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

[iyermakova]

Changes like that will not be describing FpML as FpML instant documents will require element.

[Author]

Posts