{"id":15498,"date":"2011-06-26T16:50:49","date_gmt":"2011-06-26T20:50:49","guid":{"rendered":"http:\/\/www.prefblog.com\/?p=15498"},"modified":"2011-06-26T16:50:49","modified_gmt":"2011-06-26T20:50:49","slug":"himipref-yield-calculation-change","status":"publish","type":"post","link":"https:\/\/prefblog.com\/?p=15498","title":{"rendered":"HIMIPref™ Yield Calculation Change"},"content":{"rendered":"

In the comments to the June 22<\/a> report, Assiduous Reader drap1<\/i> asked:<\/p>\n

Hi\u2026quick question about last prefletter. I\u2019ve seen this other times, but here is a clear example:<\/p>\n

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\u2019t TRP.PR.C get evaluated to its reset date?<\/p>\n

TRP.PR.C does resets a year later which could create a small difference depending on the yld curve, but I don\u2019t think that\u2019s the answer.<\/p><\/blockquote>\n

Good question! For a quick answer, here are the summaries of the two optionCalculationLists<\/a> on the pseudoPortfolioReportBox<\/a>:<\/p>\n

Report Box
\nInstrument\u2022:\u2022TRP.PR.B (Security A51015)
\nPseudoPortfolioElement: Pricing Modification – Base Option ID: Undefined
\nReporting: YTM (Port Method) at Bid
\n*****
\nEvaluated at bid price : 25.4000
\nCall 2015-07-30 YTM: 3.51 % [Restricted: 3.51 %] (Prob: 45.09 %)
\nCall 2020-07-30 YTM: 3.46 % [Restricted: 3.46 %] (Prob: 0.30 %)
\nLimit Maturity 2041-06-10 YTM: 3.47 % [Restricted: 3.47 %] (Prob: 54.61 %)
\nYTM (Port Method) : 3.4865 %<\/p><\/blockquote>\n

and<\/p>\n

Report Box
\nInstrument\u2022:\u2022TRP.PR.C (Security A51016)
\nPseudoPortfolioElement: Pricing Modification – Base Option ID: Undefined
\nReporting: YTM (Port Method) at Bid
\n*****
\nEvaluated at bid price : 25.9000
\nCall 2016-02-29 YTM: 3.65 % [Restricted: 3.65 %] (Prob: 52.02 %)
\nLimit Maturity 2041-06-10 YTM: 3.56 % [Restricted: 3.56 %] (Prob: 47.98 %)
\nYTM (Port Method) : 3.6095 %<\/p><\/blockquote>\n

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.<\/p>\n

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.<\/p>\n

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<\/a>, which is currently set to 5%. However, subsequent normalizations did not enforce this constraint.<\/p>\n

Additionally, as can be seen from the cashFlowDiscountingAnalysisBox<\/a>, the cash flows to 2020 for TRP.PR.B<\/a> 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?<\/a> due to the influence of the maturityNoticePeriod<\/a>.<\/p>\n

“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<\/a>).<\/p>\n

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:
\ni) The constraint OPTION_EXERCISE_CALCULATION_INCREMENT_PROBABILITY<\/a> is enforced during the normalization of option exercise probabilities
\nii) maturityNoticePeriod<\/a> is only accounted for when the exercise date is less than MATURITY_NOTICE_PERIOD<\/a> days from the calculation date.<\/p>\n

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.<\/p>\n

The effect of these changes on the YTW calculation is displayed in the following reports:<\/p>\n