[Quantlib-dev] AW: FpML integration - some thoughts

[Jens T. <jen...@st...>]

All the X/Q/M/S...ML stuff looks like some work todo and I'm not sure where
to start.

SML will be more like a .config file, I guess, but could equally get fetched
from a DB. First step (and already planned) is to write some string-based
factories for the various object types, so I can get eg. a 'GB', 'London' or
'GBP' calendar. Same with the other business conventions. Some of these can
not be effectively "created" from a text file and need a class to supply the
business logic, thats why I already wrote the "FactoryItemAttribute" (see
Utilies) which should be applied to all classes that can be added at
runtime. So adding new business logic would mean to add another assembly and
register its "factory items". The SML approach will be more flexible and
preferable though.

MML looks too complex... maybe even too big for Reuters, Bloomberg and
Datastream. A certain priority would be the ability to define (and pass)
term structures, either with a named handle or direcly "by value".


Things do do after holidays, I guess....


Jens.

> -----Ursprüngliche Nachricht-----
> Von: Toyin Akin [mailto:toy...@nt...]
> Gesendet: Montag, 2. September 2002 19:40
> An: Jens Thiel; qua...@li...
> Cc: anw...@ti...; jam...@ir...
> Betreff: Re: FpML integration - some thoughts
>
>
>
> I agree,
>
> The FpML engine should only really know about holding deal data
> (with enums
> corresponding to various market conventions) and knowing how to
> serialise/deserialise this to XML.
>
> In fact I would like to have 4 schemas defined.
>
> 1) Product based - FpML
> 2) Results based - QML
> 3) Market information MML (curves of various kinds, yield curves, vols
> curves, matrices, cubes, correlations etc...)
> 4) Static data - SML
>
> Thus a user will be able to not only store a deal, but also be
> able to store
> the market parameter for the pricing of that deal or all deals.
>
> Regarding SML (for the lack of a better word), it does not make sense to
> hard code all the business rules for a particular currency in C++/C# code.
> We should really store this within a file. A user should be able to simply
> pick "euribor" to price a leg and not have to figure out all the various
> conventions that apply, especially what holiday centers are specific to a
> particular reference rate both for fixing and payment dates. There are
> hundreds of reference rates floating around and most Traders/Marketers
> certainly know the ISDA definition and would like to simply pick
> from a list
> and not construct one from scratch.
>
> Also adding a new reference rate definition should not involve
> recompling a
> trading system.
>
> Also, a lot of the deals within QuantLib cannot be represented
> within FpML.
> (Equities are weakly represented, and I'm not too impressed with what's
> there already).
>
> I agree with James, we need to at least price a regular swap, with all the
> various market conventions.
> In the case of structured deals (Xccy Swap, Basis swaps, capped floaters
> etc...) you can probably use the productstrategy
> object and just store multiple trades within this object, each trade
> represents a single swapstream object. This way we know it's a structured
> deal and the pricing system can simply iterate across legs and price.
>
> Regards,
> Toy.
>
>
>
>