Archive for the ‘HIMIPref News’ Category

HIMIPref™ Bug Fix: curveYield Calculation

Friday, October 24th, 2008

As noted on October 22

I’ll explain in another post, because it’s kind of funny, but basically there’s a little loop used in the process of curve approximation that calculates a yield; in the case of YLD.PR.B, quoted at 1.60 with a stated annual dividend of $1.05 (currently suspended) until maturity 2012-2-1 at $15 [dubious], the little loop ran ’round 5,709,833 times [in the run where the problem was unequivocally isolated] before the WebService timed out and blew up the whole programme.

The function at fault (yieldApproximatorTypeCalc::getSemiAnnualYieldFromTable) calculates the yield to maturity of a set of cash flows defined in a table (the input is set up in much the same way as Excel’s XIRR() function) by successive approximations to the yield using the Newton Method.

Unfortunately, this procedure can be unstable near a horizontal asymptote or a local extremum.

When calculating the curveYield for YLD.PR.B on October 21, the function did not converge; instead, it oscillated between two highly incorrect numbers.

The function has been adjusted such that:

  • After 500 iterations, a successively smaller damping factor is applied to the yield change, and
  • After 1,000 iterations, status information is written to the errorOutput.txt file after each iteration, and
  • After 1,010 iterations the process aborts and returns ANALYTICAL_DOUBLE_NO_SOLUTION

The function now converges for YLD.PR.B on October 21; other tests (prior to application of the damping factor) confirm that the ‘no solution’ result is handled properly by the rest of the programme.

It’s not often I find a crippling bug in HMIPref™ any more! That’s the only lack of convergence in this function in almost 15 years of daily data!

HIMIPref™ Tracking of IQW.PR.D Halted

Wednesday, September 17th, 2008

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!

HIMIPref™: New Build Available 2008-09-09

Tuesday, September 9th, 2008

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.

Fixed-Reset Issues Added to HIMIPref™

Monday, September 8th, 2008

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!

Fixed-Resets: A Review

Thursday, September 4th, 2008

Well, as previously noted, despite my misgivings, I have to add the fixed-resets to the HIMIPref™ universe since:

  • There are now 10 issues outstanding, making intra-sectoral swaps a source of potential profit
  • They comprise more than 10% of the TXPR Index

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

Yield Curve Pictures – 2008-06-18

Wednesday, June 18th, 2008

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.

HIMIPref™ Evaluates Trade: TCA.PR.X -> CU.PR.A

Tuesday, March 25th, 2008

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!

Dividend Details for FIG.PR.A Not Available

Monday, March 10th, 2008

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.

AR.PR.B Removed from HIMIPref™

Wednesday, March 5th, 2008

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!

Sunlife Financial Dividend Not Yet Declared

Wednesday, February 13th, 2008

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:

  • ExDate: 2008-2-19
  • Record Date 2008-2-21
  • Pay Date 2008-3-31

… 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!