Archive for the ‘HIMIPref News’ Category

HIMIPref Data Update Delay, 2006-08-02

Wednesday, August 2nd, 2006

Uploading of the prices for 2006-08-02 will be delayed. At time of writing, 9:45pm EDT, prices were not available from the Toronto Exchange. Assuming system problems are not unduly severe, prices will be uploaded in the morning of 2006-08-03.

 And I’m going home.

 

Update, 2006-08-03, 9:30am EDT The prices have been recovered and the system is ready to go. Disregard the valuation assigned to the BC.PR.C – this is higher than it should be for technical reasons related to the change of terms

BC.PR.B / BC.PR.E

Wednesday, August 2nd, 2006

The terms of BC.PR.B changed effective 2006-05-01 with the annual dividend declining from $1.3125 to $1.0875. There’s a haircut for you!

Holders had the option to convert to the Ratchet Rate issue, BC.PR.E, and a little bit more than a quarter of the issue was converted. These issues become convertable into each other again on May 1, 2011 (although you may need to contact the company earlier!).

Changes have been put through on HIMIPref to reflect this conversion. Security codes are:

Issue Code
BC.PR.B (old) A38003
BC.PR.B (new) A38006
BC.PR.E A38007

BC.PR.C

Wednesday, August 2nd, 2006

The terms of this issue have changed, effective 2006-08-01, in accordance with the prospectus and the resetting of the coupon.

The coupon rate is now 4.65% until 2011-08-01. HIMIPref assumes that on that date it will become a Ratchet-Rate issue, since the company has discretion as to the fixed rate to which the issue will be reset.

No shares were converted to the Ratchet-Rate preferreds, since the holders of less than 2-million shares wished to exercise that privilege.

The old HIMIPref security code for this issue was A38004; following a “term change” reorganization, the new code is A38005.

TD.PR.N

Tuesday, July 25th, 2006

Mea culpa.

 I was doing some checks of the Operating Retractibles when I found that there was an error in the option schedule for TD.PR.N.

The last redemption period, to redeem at $25.00 until the end of time, begins on 2013-04-30, not 2012-04-30.

The change has been made on the server.

Why not always buy the highest valued shares?

Monday, July 24th, 2006

PrefBlog Reader Drew asked on the Comments and Requests: HIMIPref thread:

Thanks for the response. One of the reasons for my question is that I noticed recently that HIMIPref gives high valuation scores to a couple of the operating retractibles, specifically those of GWO and MFC, but instead of recommending them for purchase it recommends a perpetual issue with a lower valuation score. I do own several split share issues but no operating retractibles. Is it likely that HIMIPref is recommending the lower valuation issue due to overall portfolio risk considerations?

Well, I responded on the wrong thread, initially, but I’ll reprint it here:

 There are a number of possibilities:

(i) It may be due to weight constraints set in your constraints specifications file. It is possible to set this file such that, for instance, you would hold only perpetuals.

(ii) More likely, it is due to the relative riskDistance between the various issues. Essentially, the valuation pick-up is divided by the risk distance and it is this value that must exceed the hurdle in order for the trade to be recommended. The risk distance between a perpetual and another perpetual will normally be greater than that between a perpetual and a retractible.
The concept of risk distance was introduced on the basis that issues are more easily compared the more similar they are. In other words, you can discriminate more easily between two high quality perpetual issues than you can between a hiqh quality perpetual and a low quality split share. The second trade will have a higher risk distance than the first; the second may well have a higher raw valuation pick-up but a lower trade score.
In the “Issue Method” of trade evaluation, this concept is used by the system in an effort to ensure that each individual trade, once recommended, has an equal chance of being profitable.
In the “Portfolio Method”, risk distance is measured from the pre-trade portfolio to the index and then from the post-trade portfolio to the index, in an effort to ensure that a portfolio mis-match of risk characteristics from the index is justified by excess expected return.

What about risk control?

Friday, July 21st, 2006

Prefblog reader Drew asks on the Comments and Requests: HIMIPref thread:

My impression is that HIMIPref does not merely select the most attractive issues for purchase but rather factors in the relative risks between different categories of preferred shares – chiefly retractible versus perpetual – with a view to constructing a safer portfolio than if the focus was placed solely on the most attractive issues. Is my impression correct?

This impression is essentially correct. A lot of thought has gone into the risk control aspects of HIMIPref, although the exercise of these controls is much more explicit when optimizing according to the portfolio method than with the issue method.

 With the parameterization currently supplied with HIMIPref for the issue method, a great deal of emphasis is placed on the potential for trading profits and the value of each issue relative to its price given all its risk attributes. Thus, the primary comparison for a split-share, for example, is other split shares; comparisons to perpetuals have a great influence, but are less important. It is unlikely that any class of shares could have so many issues far above the curve that they totally dominate other classes … after all, if there were too many issues like this, then the curve itself would move!

Thus, a certain amount of diversification of risk-attributes is built into the trading model. Should the subscriber wish it, this diversification can be amplified or reduced, by fiddling with the constraintSpecificationRecord that resides on the client-side.

BNA.PR.A

Friday, July 21st, 2006

I was writing a piece about negative Yield-to-Worst as it affected index reporting and decided that I should check BNA.PR.A to see how much of it had been redeemed to date … to my horror, I found that the terms of the issue had been changed on 2003-08-21 and I’d missed it.

The change has been put through to the server-side data. If any clients happen have a position in this issue, the security code will have to be changed on the client-side transactions and holdings files. The old Security Code was A37700; the new code is A37702.

 The only information I’ve found on this change of terms has been in SEDAR and I can’t link to anything there according to the Terms of Use.

 As for the YTW after the change … well, let’s just say it’s not negative any more!