Re: FpML integration - some thoughts

[James Battle]

Jens,

Sounds like a good idea.

Agreed , at the moment FpML is basically a product definition.  There's some
work starting that will add standard business transactions such as 'Request
for
Quote' etc, but this will be some time coming and still won't fit that well
with
what QuantLib does which is calculation.

I think a great start would be to be able to correctly price the simple
instruments
such as swaps.

Of course the concept of 'price' has to be defined, because there are
potentially
dozens of things that could be solved for.  e.g. in FpML a basis swap will
only
appear different in the message to an IRS, because it has two floating legs.
The
FpML instruments are relatively vanilla, but the danger is that an engine
would
get the classification wrong.  e.g. not seeing an embedded Bermudan option
in
the swap ... or seeing the Bermudan, but not realising that the date
schedule has
been customised to be non-standard etc etc.

Getting this low-level stuff rock solid would involve some useful upgrades
to the
base QL such as handling schedule dates as pointed out by Toyin a while
back.

James Battle

FpML Architecture Working Group/
Ironbark Limited

Tel: [phone]
Web: http://www.ironbark.co.uk


----- Original Message -----
From: "Jens Thiel" <[hidden email]>
To: <[hidden email]>
Cc: <[hidden email]>; <[hidden email]>;
<[hidden email]>
Sent: Monday, September 02, 2002 12:38 PM
Subject: FpML integration - some thoughts


>
> 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.
>
>
>