IndexedCoupon and possible convexity adjustment

[Luigi Ballabio-2]

Hi all,
        right now, IndexedCoupon implements its fixing() and amount()  
methods (neglecting any spreads for clarity) as:

fixing() => return index_->fixing(fixingDate());
amount() => return fixing() * accrualPeriod() * notional()

However, a convexity adjustment might be necessary (for instance,  
InArrearIndexedCoupon needs one although none is currently provided.)
My question is, to which method it should be added? Leaving aside for  
the time being the problem of calculating the adjustment, should we  
write the two above methods as:

fixing() => return index_->fixing(fixingDate()) + adjustment();
amount() => return fixing() * accrualPeriod() * notional()

or (more to my liking) as:

fixing() => return index_->fixing(fixingDate());
amount() =>
    return (fixing()+adjustment()) * accrualPeriod() * notional()

In other words, what would a user (you) expect from the fixing() method  
of a coupon based on an index---simply the theoretical fixing of the  
index, or the convexity-adjusted value?

Or should the convexity adjustment be taken into account only when  
discounting the amount? (Which would make me shudder as the convexity  
adjustment should be moved all the way up to the CashFlow interface?)

Later,
        Luigi

[Luigi Ballabio-2]

On 2004.08.31 10:52, [hidden email] wrote:
> Hi all,
> I think that a convexity adjustment should be introduced.
> In my opinion- but it is just my opinion-
> it would be better to be inserted in the fixing,
> since it is a proper correction to the rate's value.

Ok, one vote for adding it to fixing().

> My question is: should it be the case to insert it directly into the
> Xibor?

No, I think it should be inserted (as a virtual method) into  
IndexedCoupon. After all, the convexity is due to the fixing being  
accrued over a period which is not its natural one--i.e., is due to the  
fixing being used in a coupon. The fixing() method of IndexedCoupon  
would adjust the value returned from Xibor::fixing() instead of just  
proxying it. Also, the calculation of the adjustment might require  
other dates besides the fixing date which are available to the coupon  
but not to the Xibor.

> This could be usefull when constructing other classes
> (suppose a floating rate note) which require Xibor and convexity
> adjustment.

The floating rate note would delegate the calculation to the coupon,  
instead of using the Xibor directly.

> Another idea since we are talking about convexity adjustment:
> It would be great to insert a CMS index as well. It is widely used
> and in this case the adjustment is really significant.

Yes, it could be done--the CMS index would return the forward swap  
rate, and the CMS coupon (deriving from IndexedCoupon) would adjust it.

Later,
        Luigi

[Ferdinando M. Ametrano-3]

Hi Luigi

>what would a user (you) expect from the fixing() method
>of a coupon based on an index---simply the theoretical fixing of the
>index, or the convexity-adjusted value?

In my opinion a fixing is a fixing: it belongs to the underlying index_
more than to any coupon and it shouldn't be adjusted.
I would keep a fixing() method in the coupon as a simple proxy to the
underlying index and add an accrualRate() method that could be (neglecting
any spreads for clarity):

accrualRate() => return index_->fixing(fixingDate()) + adjustment();

or even better:

accrualRate() => return *this->fixing(fixingDate()) + adjustment();

ciao -- Nando

[Ferdinando M. Ametrano-3]

Hi all

Luigi wrote:
>[hidden email] wrote:
>>It would be great to insert a CMS index as well. It is widely used
>>and in this case the adjustment is really significant.
>
>Yes, it could be done--the CMS index would return the forward swap
>rate, and the CMS coupon (deriving from IndexedCoupon) would adjust it.


c'mon Enrico: time to contribute your CMS index to QuantLib ;-)

ciao -- Nando

[Nicolas Di Césaré]

Hi all,

Le mar 31/08/2004 à 11:50, Ferdinando Ametrano a écrit :
> Hi Luigi
> >what would a user (you) expect from the fixing() method
> >of a coupon based on an index---simply the theoretical fixing of the
> >index, or the convexity-adjusted value?
>
> In my opinion a fixing is a fixing: it belongs to the underlying index_
> more than to any coupon and it shouldn't be adjusted.

Nando, I share your opinion : "a fixing is a fixing" and I think that
expected cashflows should be calculated in the PricingEngine. That
allows to "easily" compute in-arrear  and CMS (once the index is created
:-) cashflows using your favorite convexity-correction formulas.




--
Nicolas Di Césaré <[hidden email]>