FpML integration - some thoughts

[Jens Thiel]

Hi all,

I had some thoughts over FpML integration and would like to make my ideas
available for discussion:

FpML is a more product/business-oriented representation, whereas QuantLib
has its (current) strengths on the calculation side. Separating the business
rules from the calculation may even be favourable, so I would suggest to
define an XML schema solely for calculating and returning results: QML. On
top of that, we can re-implement the existing calculation engines and
validators.

This would allow us to write a very transparent and generic FpML (or
'structured product') to QML translation, where all business rule related
conversions and data access are handled by a separate layer. At the same
time, QML can also serve as a well-defined non-binary interface to QuantLib.

If you see any problems with this approach, or have further suggestions:
your feedback is always welcome!

Regards,

Jens.

[Toyin Akin-2]

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.

[Jens Thiel]

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:[hidden email]]
> Gesendet: Montag, 2. September 2002 19:40
> An: Jens Thiel; [hidden email]
> Cc: [hidden email]; [hidden email]
> 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.
>
>
>
>

[Toyin Akin-2]

Hi,

Reuters are defining a XML format called MDDI.

I haven't played with it yet, but it seems to handles all types of realtime
market data.

However I don't think this is in QuantLib's mandate.

Regards,
Toy.