QuantLib › quantlib-users

Cash flow treatment of range accrual notes

Classic

List

Threaded

3 messages Options

Haoyun XU

Cash flow treatment of range accrual notes

Hi All,

I have a question on pricing equity-linked range accrual notes. For each period, the coupon is accrued daily and the accumulated payment is delivered at the end of each period. That means the real cash flow only happens on period ends. Either we can price the cash flow on a accrual basis - assume coupon is payed on a daily basis with proper discounting, or we can price it on the real cash flow - one lump sum coupon payment at period end.

I wonder which one is the common practice.

Regards & Thanks!

Henry

------------------------------------------------------------------------------
Rapidly troubleshoot problems before they affect your business. Most IT
organizations don't have a clear picture of how application performance
affects their revenue. With AppDynamics, you get 100% visibility into your
Java,.NET, & PHP application. Start your 15-day FREE TRIAL of AppDynamics Pro!
http://pubads.g.doubleclick.net/gampad/clk?id=84349831&iu=/4140/ostg.clktrk
_______________________________________________
QuantLib-users mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/quantlib-users

Peter Caspers-4

Re: Cash flow treatment of range accrual notes

Hi Henry,

is this question related directly to quantlib (if yes, to which part
of the code) ?

In general (and with the disclaimer that I am not an equity man), I
would say the price of one rangelet is uniquely identified as P(0,t_p)
\tau E^{t_p} ( S(t_f) ) with t_p the payment time, t_f the fixing
time, S the equity spot, \tau the day count fraction for the
contribution to the coupon of this fixing and P(0,t_p) today's zero
coupon price with maturity t_p and the expectation is taken in the t_p
- forward measure. Of course you can work in a different measure, but
results will of course stay identical. Not much room for
interpretation, I guess.

To take the example of a monte carlo simulation it wouldn't matter if
you account for each contribution on its respective fixing date t_f
separately as \tau N(0) S(t_f) P(t_f,t_p) / N(t_f) (with arbitrary
numeraire N now) or collect the contributions \tau S(t_f) on your way
to the payment date and consider N(0) [ \sum \tau_i S(t_{f,i}) ] /
N(t_p) there. The final result (in terms of the NPV of the range
coupon) would be the same.

Peter

On 3 January 2014 11:21, Haoyun XU <[hidden email]> wrote:

> Hi All,
>
> I have a question on pricing equity-linked range accrual notes. For each
> period, the coupon is accrued daily and the accumulated payment is delivered
> at the end of each period. That means the real cash flow only happens on
> period ends. Either we can price the cash flow on a accrual basis - assume
> coupon is payed on a daily basis with proper discounting, or we can price it
> on the real cash flow - one lump sum coupon payment at period end.
>
> I wonder which one is the common practice.
>
> Regards & Thanks!
> Henry
>
> ------------------------------------------------------------------------------
> Rapidly troubleshoot problems before they affect your business. Most IT
> organizations don't have a clear picture of how application performance
> affects their revenue. With AppDynamics, you get 100% visibility into your
> Java,.NET, & PHP application. Start your 15-day FREE TRIAL of AppDynamics
> Pro!
> http://pubads.g.doubleclick.net/gampad/clk?id=84349831&iu=/4140/ostg.clktrk
> _______________________________________________
> QuantLib-users mailing list
> [hidden email]
> https://lists.sourceforge.net/lists/listinfo/quantlib-users
>

------------------------------------------------------------------------------
CenturyLink Cloud: The Leader in Enterprise Cloud Services.
Learn Why More Businesses Are Choosing CenturyLink Cloud For
Critical Workloads, Development Environments & Everything In Between.
Get a Quote or Start a Free Trial Today.
http://pubads.g.doubleclick.net/gampad/clk?id=119420431&iu=/4140/ostg.clktrk
_______________________________________________
QuantLib-users mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/quantlib-users

Peter Caspers-4

Fwd: Cash flow treatment of range accrual notes

upps, below you should replace S(t_f) by F ( S(t_f) ) with F an
indicator for the range condition multiplied by the coupon rate...

the npv should always contain the cashflows with (real) payment date
later ( / later or on ) settlement date, the fixing date is not
relevant for this. Even if an engine moves a cashflow around in time
for its convenience, in the end the actual payment date should be the
criterion to include the cashflow into the npv. (on top of that it may
be easier to look at the pl theta, not the npv theta to avoid jumps on
payment dates)

Peter

On 10 January 2014 02:50, Haoyun XU <[hidden email]> wrote:

> Dear Peter,
>
> Thanks for your reply.
>
> This question arise when I am looking into the finite difference engine, I
> wonder how QuantLib handles accumulated cash flows as in the case of
> equity-linked range accrual notes, where both optionality and cash flow
> exist.
>
> I could not find a clue in the code, or maybe I just missed it. So you can
> take it as a general question.
>
> Yes, as you said, we can do it in either way, the final result (NPV) is the
> same.
>
> But there is one concern for me when pricing the mark to market value of an
> existing trade. If we consider real cash flows at fixing dates only, it may
> have a jump around the fixing dates, which means unusual theta. Otherwise,
> if we consider the cash flow accumulated everyday, the price will be smooth
> accrossing the fixing dates.
>
> Please correct me if i am wrong.
>
> Best regards,
> Henry
>
>
>
>
> 2014/1/10 Peter Caspers <[hidden email]>
>>
>> Hi Henry,
>>
>> is this question related directly to quantlib (if yes, to which part
>> of the code) ?
>>
>> In general (and with the disclaimer that I am not an equity man), I
>> would say the price of one rangelet is uniquely identified as P(0,t_p)
>> \tau E^{t_p} ( S(t_f) ) with t_p the payment time, t_f the fixing
>> time, S the equity spot, \tau the day count fraction for the
>> contribution to the coupon of this fixing and P(0,t_p) today's zero
>> coupon price with maturity t_p and the expectation is taken in the t_p
>> - forward measure. Of course you can work in a different measure, but
>> results will of course stay identical. Not much room for
>> interpretation, I guess.
>>
>> To take the example of a monte carlo simulation it wouldn't matter if
>> you account for each contribution on its respective fixing date t_f
>> separately as \tau N(0) S(t_f) P(t_f,t_p) / N(t_f) (with arbitrary
>> numeraire N now) or collect the contributions \tau S(t_f) on your way
>> to the payment date and consider N(0) [ \sum \tau_i S(t_{f,i}) ] /
>> N(t_p) there. The final result (in terms of the NPV of the range
>> coupon) would be the same.
>>
>> Peter
>>
>> On 3 January 2014 11:21, Haoyun XU <[hidden email]> wrote:
>> > Hi All,
>> >
>> > I have a question on pricing equity-linked range accrual notes. For each
>> > period, the coupon is accrued daily and the accumulated payment is
>> > delivered
>> > at the end of each period. That means the real cash flow only happens on
>> > period ends. Either we can price the cash flow on a accrual basis -
>> > assume
>> > coupon is payed on a daily basis with proper discounting, or we can
>> > price it
>> > on the real cash flow - one lump sum coupon payment at period end.
>> >
>> > I wonder which one is the common practice.
>> >
>> > Regards & Thanks!
>> > Henry
>> >
>> >
>> > ------------------------------------------------------------------------------
>> > Rapidly troubleshoot problems before they affect your business. Most IT
>> > organizations don't have a clear picture of how application performance
>> > affects their revenue. With AppDynamics, you get 100% visibility into
>> > your
>> > Java,.NET, & PHP application. Start your 15-day FREE TRIAL of
>> > AppDynamics
>> > Pro!
>> >
>> > http://pubads.g.doubleclick.net/gampad/clk?id=84349831&iu=/4140/ostg.clktrk
>> > _______________________________________________
>> > QuantLib-users mailing list
>> > [hidden email]
>> > https://lists.sourceforge.net/lists/listinfo/quantlib-users
>> >
>
>