HIMIPref™ Yield Calculation Change

In the comments to the June 22 report, Assiduous Reader drap1 asked:

Hi…quick question about last prefletter. I’ve seen this other times, but here is a clear example:

With respect to TRP.PR.B and TRP.PR.C, TRP.PR.C has a higher dividend, higher reset price and higher market price (both are above $25); however, your model evaluates TRP.PR.C to perpetuity, but TRP.PR.B, to its reset date. What am I missing? Why doesn’t TRP.PR.C get evaluated to its reset date?

TRP.PR.C does resets a year later which could create a small difference depending on the yld curve, but I don’t think that’s the answer.

Good question! For a quick answer, here are the summaries of the two optionCalculationLists on the pseudoPortfolioReportBox:

Report Box
Instrument•:•TRP.PR.B (Security A51015)
PseudoPortfolioElement: Pricing Modification – Base Option ID: Undefined
Reporting: YTM (Port Method) at Bid
*****
Evaluated at bid price : 25.4000
Call 2015-07-30 YTM: 3.51 % [Restricted: 3.51 %] (Prob: 45.09 %)
Call 2020-07-30 YTM: 3.46 % [Restricted: 3.46 %] (Prob: 0.30 %)
Limit Maturity 2041-06-10 YTM: 3.47 % [Restricted: 3.47 %] (Prob: 54.61 %)
YTM (Port Method) : 3.4865 %

and

Report Box
Instrument•:•TRP.PR.C (Security A51016)
PseudoPortfolioElement: Pricing Modification – Base Option ID: Undefined
Reporting: YTM (Port Method) at Bid
*****
Evaluated at bid price : 25.9000
Call 2016-02-29 YTM: 3.65 % [Restricted: 3.65 %] (Prob: 52.02 %)
Limit Maturity 2041-06-10 YTM: 3.56 % [Restricted: 3.56 %] (Prob: 47.98 %)
YTM (Port Method) : 3.6095 %

So part of the problem is a stenographical error: I should have specified that the call on TRP.PR.B was calculated to the second reset date but, frankly, missed that when transcribing the table.

However, the interesting question is the appearance of second reset date in the TRP.PR.B table but not in the TRP.PR.C table, particularly given that the probability of exercise of this option is less than half a percent.

Possible options are added to the calculation list only if the probability of exercise, when initially calculated, is greater than the value OPTION_EXERCISE_CALCULATION_INCREMENT_PROBABILITY, which is currently set to 5%. However, subsequent normalizations did not enforce this constraint.

Additionally, as can be seen from the cashFlowDiscountingAnalysisBox, the cash flows to 2020 for TRP.PR.B extend one month further than the actual call date, as has been previously discussed on PrefBlog in the post What is the Yield of RY.PR.Y? due to the influence of the maturityNoticePeriod.

“Cliff Effects” are a bugaboo in all analysis and have been blamed, at least in part, for the Panic of 2007 (since a credit rating downgrade raised the capital requirements for all regulated holders, who therefore all had a strong prediliction to sell at the same time). By its nature, YTW is subject to cliff effects, at least insofar as it comes to reporting the duration of the YTW scenario (the amount of change in duration for relatively small changes in price is measured by the attribute pseudoConvexityWorst).

Two changes in programming have been made that should make the calculations at least little easier to explain, although cliff effects will still be present:
i) The constraint OPTION_EXERCISE_CALCULATION_INCREMENT_PROBABILITY is enforced during the normalization of option exercise probabilities
ii) maturityNoticePeriod is only accounted for when the exercise date is less than MATURITY_NOTICE_PERIOD days from the calculation date.

I have been toying with the second idea for quite some time and the change will save me a lot of explanations regarding yield calculation. I’ve resisted the idea because (a) as far as I can tell, it won’t make much difference and (b) a complex analytical programme is a chaotic system, meaning that small changes to some parts can cause huge differences in output under certain conditions. But now seems as good a time as any to proceed.

The effect of these changes on the YTW calculation is displayed in the following reports:

Leave a Reply

You must be logged in to post a comment.