Well, it happened last March with AR.PR.B and now it’s happened again.
In my last update of the day everything IQW.PR.D was one penny bid and the quote was rejected as an obvious error. Ha!
The issue has been around in various incarnations since 1997-11-12, when it came on the scene as IQI.PR.A. Ave Atque Vale!
As mentioned previously, differences in spreads for Floating Rate issues require a new build every time there is a new spread defined. Very annoying; if this craze for Fixed-Resets continues, I’ll have to try the hypervariable-code-as-Web-Service solution previously noted.
The Royal Bank new issue, with its heretofore unheard-of +193bp spread, has required a new build. This build is available from the usual place.
As promised, Fixed-Reset issues have been added to the HIMIPref™ database.
Additionally, a new HIMIPref™ sub-index has been added, the Fixed-Reset Index.
Minor, but annoying programming changes were required in order to add these issues. Each Floating-Rate issue requires what is currently a hard-coded schedule, specifying the base index to be used for the issues and the calculations required to obtain the projected floating-rate. This has been an easy matter in the past, since there have not been many new floaters added and since those that have been added have fit comfortably into extant classifications (e.g., Ratchet Rate, Canada Prime, max 100% of index, min 50% of index). Fixed-Resets, however, have a spread specified in terms of basis points; in order to specify the future floating rate for the current ten issues, nine different spreads neede to be hard coded.
Therefore, HIMIPref™ users must download the new executable in the usual way. Don’t forget to back up user files prior to installation!
There is a possibility that I might isolate the hypervariable sections of code and place them in a new web-service, with calculations and descriptions to be downloaded on the fly. This would mean that the front-end could stay constant; to add a new floating rate specification I would simply recode and reinstall the service on server-side, invisibly to users. However, I have not yet determined that this concept is practically possible or, if possible, whether or not it will simply lead to spaghetti code making future enhancements possible. Until I’ve made a decision, users will simply have to re-download and re-install the front-end every time the issuers come up with a new spread!
Well, as previously noted, despite my misgivings, I have to add the fixed-resets to the HIMIPref™ universe since:
So, not being one to wish to waste perfectly good notes, I thought I’d review the characteristics of the issues so far:
| Fixed-Reset Issues Announced or Issued to September 4, 2008 |
|||
| Ticker | Initial Rate |
Reset Spread |
First Exchange Date |
| TD.PR.? | 5.00% | 196 bp | 2014-1-31 |
| CM.PR.? | 5.35% | 218 bp | 2014-7-31 |
| BNS.PR.? | 5.00% | 188 bp | 2014-1-25 |
| TD.PR.Y | 5.10% | 168 bp | 2013-10-31 |
| BMO.PR.M | 5.20% | 165 bp | 2013-8-25 |
| NA.PR.N | 5.375% | 205 bp | 2013-8-15 |
| TD.PR.S | 5.00% | 160 bp | 2013-7-31 |
| BNS.PR.Q | 5.00% | 170 bp | 2013-10-25 |
| FTS.PR.G | 5.25% | 213 bp | 2013-9-1 |
| BNS.PR.P | 5.00% | 205 bp | 2013-4-25 |
Those wishing to wallow in the extreme awfulness of current market conditions may wish to look at the HIMIPref™ graphs of the yield curve for March 31, 2007 (the peak, approximately), November 30, 2007 (the prior trough, approximately) and today (the new trough).
The curves represent spot rates, not yields-to-maturity. A single instrument will use the one-year rate to discount its dividend receivable in one year, the two year rate to discount the dividend receivable in two years, the three year …
When looking at the curve, note that it is computed with tax rates of 21.00% on dividend income; 46.4% on interest income and 23.20% on capital gains. Also note that this represents the core curve (instrument rated Pfd-1, dividend-paying, non-cumulative, operating company, non-retractible, average volume, fixed dividend) … instruments with varying characteristics will find themselves shifted off the curve in accordance with the current best-fit parameters.
For the formula used when fitting the curve, see the glossary entries on the yield curve.
This potential trade was discussed in the comments to a post that posed the question: TCA.PR.X & TCA.PR.Y : What’s Keeping Them Up?.
So … just for fun, I created a portfolio which held two issues, TCA.PR.X and TCA.PR.Y, 1,000 shares of each. I defined the portfolio as trading according to the issueMethod, with a desired number of issues equal to 2.
I produced a number of reports, most of which will look like complete gobbledy-gook. You can start tracing their meanings with some help from the glossary:
So … the vital number is the trade score … “100” means the trade is recommended even at bid to full offer; “0” means the trade is recommended at full offer to bid (i.e., OK if you can sell at the offering price and buy at the bid price). In this case the trade score is -1,773 … the trade is so far away from being recommended we might just as well stay home.
Looking at the trade evaluation, though, we do see there’s a pretty good pickup; the trade is not recommended because the required pickup is enormous … ridiculously enormous, in fact. It would be very rare for a potential trade to meet such a hurdle.
Looking at the Risk Measurement report, we find that the required pickup is ridiculously big because the change in pseudoConvexityCost is ridiculously big.
The calculation of pseudoConvexityCost in HIMIPref™ is not something I’m very happy with. It will be changed in the next version of HIMIPref™, but I have to play with it. The problem is that in some conditions, the numbers are implausible and counter-intuitive … this is prevented from fooling the trade recommendation engine by various checks and catches in that part of the programme … but I still don’t like it.
Anyway, the derivation of the extremely high pseudoConvexityCost for TCA.PR.X can be traced (part of the way down the route) with:
There’s more in the system. To understand costYield, you have to look at the cash flows, in which the embedded option is treated as a cash flow adjustment to a permanent revenue stream. In order to understand the pricing of the embedded option, you have to look at that report. But, geez, that’s enough detail for one day, eh?
Suffice it to say that pseudoModifiedDurationCost (that is to say, the modified duration calculated, not formulaicly, but by sampling of yield changes, using costYield as the yield measure) changes a lot for TCA.PR.X given its present price. The system has found (via backtesting) that trades that change this number substantially are riskier (in terms of ultimate results) than trades that do not change this number.
So in this case, the system wants to hang on to the existing issue – even though the valuation of CU.PR.A is higher – because the risk profile is so different.
Astute readers will have noticed that the trade size was reduced to zero due to the low volume on the CU.PR.A anyway!
No information regarding the relevant dates for the interest payment on FIG.PR.A is currently available, either on the sponsor’s website or via the TSX.
Dates have been estimated as 3/20, 3/25, 4/1.
This is actually rather amusing.
Those familiar with my work will know that I’m somewhat obsessive about errors. They can creep in anywhere, with severe consequences for quantitative systems! I therefore have the philosophy: if anything can be checked, it should be checked!
A number of these checks occur in the calculation of flatBidPrice. The programme calculates the so-called accruedDividend either by using the two actual dividendRecords, or by estimating the next dividend by using the appropriate fields of the instrumentDataRecord, if necessary.
AR.PR.B has a par value of $50 and is supposed to pay a dividend of $2.70 annually. Poor old Argus has been in default for years, but that’s what it’s supposed to do. And it turns out that the accruedDividend as of 2008-3-5 should be about $0.26.
But! Here’s where the check comes in! What if the next dividend record is screwed up, or something else horrible has occured? What if, due to some glitch or other, the data shows that the next dividend should be $1,000? This is something that can be checked and therefore should be checked. The form of the control is: The calculated accrued dividend must be less than the bid price of the security … if anything, this is a rather generous error tolerance, but when this sort of error occurs it’s usually not just for a few pennies.
So the accrued dividend calculated today was about $0.26 … and the bid price is $0.25. ERROR!
AR.PR.B, which has been tracked by HIMIPref™ from the very earliest date in the database, has now had its coverage halted. A reorg entry has been added with a reorgType of REORG_DISCONTINUED and a take-out price of $0.25.
Ave atque vale!
The headline says it all! There’s nothing on their website and a VERY EXPENSIVE data inquiry to TSX Market Data returns no declarations in the last three months.
Data have been estimated as:
… which is consistent with both the last dividend (ex-date 11/19) and last year’s 1Q dividend (ex-date 2/19) but is still just a guess.
Sunlife directors! Get with the programme! Surely preferred share dividends can be declared a month in advance of the ex-date and posted on your website! Surely a notice of expected dividends, “if, as and when”, could be posted in your investor relations section!
In line with the previously noted redemption of EN.PR.A, and the subdivision afterwards:
Immediately following the redemption of the ROC Preferred Shares and upon the completion of the reorganization, in order to maintain the ratio of Capital Yield Shares to ROC Preferred Shares of two-to-one, the Company will subdivide the remaining 650,131 ROC Preferred Shares such that there will be approximately 1.82 ROC Preferred Shares outstanding following the subdivision for every ROC Preferred Share outstanding immediately prior to the subdivision resulting in a total of 1,183,343 ROC Preferred Shares outstanding after the subdivision. ROC Preferred Shares are currently redeemable for a cash amount equal to the lesser of (i) $25.00 and (ii) Unit Value. After the subdivision, the outstanding ROC Preferred Shares will be redeemable for a cash amount equal to the lesser of (i) $13.74 and (ii) Unit Value and will be entitled to, effective December 16, 2007, quarterly fixed distributions of $0.1718. On an annualized basis, the new fixed distribution would represent a yield of 5.00% on the redemption price of $13.74.
… the TSE has reset the price to 13.324. They closed today at 12.77-20.99 (!) on zero volume.
Update, 2007-12-13: The HIMIPref™ database has been adjusted to reflect the change. A reorgDataEntry has been processed to reflect a change in securityCode from A43140 to A43141 at a rate of 182 new for 100 old.