Mea culpa.
HIMIPref™ had estimated the dividend dates for the captioned issues as 5/8, 5/10, 6/1 … I now see that the actual dates are 5/15, 5/17, 6/1.
The dividendDataRecords in the HIMIPref™ permanentDatabase have been corrected. Sorry.
Archive for the ‘HIMIPref News’ Category
HIMIPref™ Data Change: CU.PR.A & CU.PR.B Dividend Dates
Tuesday, May 8th, 2007Average Volume Calculation for New Issues
Saturday, May 5th, 2007Recently, assiduous reader Drew had some questions about the volume-average calculation of the recent new issue CFS.PR.A.
The HIMIPref summary screen indicates that the average trading volume of CFS.PR.A is 119,000 shares, well in excess of its volume over the recent past. Could you please explain this. I am guessing that higher liquidity is positive for valuation and vice versa. If this guess is correct, what sort of impact would the actual trading volume of CFS have on its valuation score?
…that would require an average trading volume of 10000 shares. Unless my memory is deceiving me again, it does not trade anything like that volume on an average basis. Today’s trading volume of 2000 seems closer to average, if a little high.
To understand the design decisions that have been made, it is necessary to understand the two major uses of volume-average in the HIMIPref™ system (which are fed into the model via averageTradingValue:
- the averageTradingValue is used to create a liquidityMeasure, that quantifies the dollar value traded vs. other issues. This measure (which is capped) is fed into the yield curve calculation and the yieldCurvePremiumLiquidity is calculated. In other words, it is considered that there is a spread to the curve assigned to the marketplace for liquidity, just as there is a spread assigned for credit ratings and everything else. When the curve gets re-applied to the instrument’s characteristics to determine the curvePrice of the instrument, the dollars-and-cents value of the instrument’s liquidity then becomes part of its valuation.
- During simulations, it is assumed that a portfolio can sell one-half of the volume-average at the bid price, or buy this quantity at the ask price.
For many years, the first point was moot. I was unable to discern any premium paid in the marketplace for liquidity – every day’s premium was 0.00%, or at at most one or two bp, the effect of mathematical accidents more than anything else. This changed a few years ago. Hesitantly at first, and then with increasing ferocity, the mathematical model started to assign a premium to liquidity which now stands at about 17bp per liquidity unit; the range of values of the liquidity unit varies between -1 and +2. Hence, liquidity has become more important to the marketplace.
Now, what of new issues? When issues are announced, they are valued on a preIssue basis, with the volume-average deemed to be 100,000 shares. This figure is fairly arbitrary – all I can say is that it seems to work pretty well, most of the time. As soon as the the issue starts trading, the volume will decline below this figure after a week (usually!) and the value for volume-average (and hence, the value of the liquidity curvePriceComponent) will decline with it. This will basically take the path of an exponential moving average – see the various links in this post for an explanation.
The trouble with CFS.PR.A is that it turned out to be a ridiculously small issue – only 1,610,000 shares were issued (virtually all to retail, I’ll warrant) – so the 100,000 estimate of average trading volume was very, very high. The daily volume of the issue (see graph) hasn’t been much at all and hence the decay of volume-average has been a relatively smooth curve (graph) that still hasn’t declined to a reasonable estimate of what the volume actually is.
The system works better with issues of normal size and trading patterns, like the recent new issue SLF.PR.E. I have uploaded a graph comparing volume-averages, as well as a graph of the SLF.PR.E daily spot volumes.
So … CFS.PR.A does (as far as I can tell) have a volume-average (and hence a valuation) that is over-estimated by HIMIPref™. That part’s easy. What’s more difficult is deciding what, if anything, to do about it. If I get any ideas, I’ll programme them!
New Issue : S Split Corp 5.25% Retractibles
Monday, April 30th, 2007I had a look at the prospectus, as promised, and have added this issue to the HIMIPref™ Universe.
Maturity is 2014-12-1. There are no intervening redemptions.
Dividend is 5.25% p.a., payable monthly, par value $10.00. There will be no distributions to the Capital Unitholders if this would result in asset coverage for the prefs falling below 1.65:1.
Underlying security is shares of BNS. The manager is covering the cost of issue – in exchange, the manager gets a fee (payable by the retracting shareholder) if units are retracted prior to maturity. Hence, asset coverage will initially be (very close to) 2.5:1. Since BNS yields approximately 3.12% p.a., income coverage at issue will be in excess of 1:1.
Downside is: DBRS rating of Pfd-2(low). I suspect that the issue lost a notch due to a very high concentration risk on BNS, but that’s for DBRS to say and for the rest of us to guess. Additionally, the maximum issue size is only $100-million. If they can get that high, it will be a respectable size as far as split-shares go, but trading may be expected to require patience.
A nice little issue, worthy of consideration as part of a DIVERSIFIED portfolio. Did I mention that a portfolio containing this issue should be DIVERSIFIED? Don’t come running to me if you have to sell 1,000 shares in two years and the price moves a buck. Or if BNS finds out they’ve made a little arithmetic error on their commodities trading and there won’t be any dividends for the next few years. Or whatever.
And while the preferred will be offered separately, there is no guarantee that they will be offered to YOU separately. The prefs are quite attractive enough that they should trade at a premium to par immediately upon issue.
The preIssue securityCode for this issue is P71400.
FFN.PR.A : Term Extension Approved
Tuesday, April 24th, 2007Shareholders in Financial 15 Split Corp. II have approved the term extension to Dec. 1, 2014:
Shareholders were asked to consider a special resolution to amend the articles of the Company to extend the termination date for the Class A Shares and the Preferred Shares to December 1, 2014.
Preferred Shareholders voted 98.5% in favour of the resolution and Class A Shareholders voted 93.8% in favour of the resolution, and therefore the resolution to extend the termination date to December 1, 2014 was approved at the meeting held earlier today.
PrefInfo.com and the HIMIPref™ database will be updated with the new scheduled redemption date shortly.
Update: Updates have been completed. A reorgDataEntry has been processed in HIMIPref™ with the reorgType REORG_TERMCHANGE changing from the old securityCode A45260 to the new securityCode A45261 … and of course, all the other permanentDatabase tables changed as required to describe the new instrument.
DFN.PR.A : Term Extension Approved
Tuesday, April 24th, 2007The Special Resolution to extend the term of DFN.PR.A to December 1, 2014 has been approved:
Preferred Shareholders voted 99.5% in favour of the resolution and Class A Shareholders voted 97.6% in favour of the resolution, and therefore the resolution to extend the termination date to December 1, 2014 was approved at the meeting held earlier today.
PrefInfo.com and HIMIPref™ will be updated to reflect the new information shortly.
Update: Updates have been completed. A reorgDataEntry has been processed in HIMIPref™ with the reorgType REORG_TERMCHANGE changing from the old securityCode A43060 to the new securityCode A43061 … and of course, all the other permanentDatabase tables changed as required to describe the new instrument.
HIMIPref™ Data Simplification : FIG.PR.A Dividends
Tuesday, April 24th, 2007As assiduous readers will remember, FIG.PR.A was the “target security” in a four way merger earlier this year.
In what was presumably an effort to ensure that each class of shareholder got their due, FIG.PR.A paid a partial dividend of 0.05308 on 2007-2-9 to holders of record 2007-1-31. They then paid the balance ($0.10317) of the regular quarterly amount on 2007-4-2 to holders of record 2007-3-22.
Unfortunately, this sort of thing gives HIMIPref™ stomach-ache. There are several layers of checks built into the system to ensure that quarterly dividends are recorded quarterly, by billy-dam, or at least approximately. The good old Argus preferreds, for instance, have been in default for … a while … but on every dividend date I dutifully put in a dividend of $0.0001, just so the programmatic editors will see the entry and tick off their lists. There’s a wobble allowed, so that issuers like ABK.PR.C with their idiosyncratic ideas regarding the definition of “regular” and “quarterly” don’t cause me too many problems.
However, things like special dividends throw me for a loop. I can handle it on redemptions, but not with a continuing security. Therefore:
1: The dividend of 0.05308 paid 2/9 has been deleted from HIMIPref™
2: The dividend of 0.10317 paid 4/2 has been entered on the system as $0.15625.
This approximation means that intra-period returns on FIG.PR.A will be miscalculated.
It also means that in simulations, returns on holdings of FCN.PR.A / FCF.PR.A & FCI.PR.A will be overstated. But it’s either that, or re-write my edit routines to be even more complicated (which I might do eventually, but hardly seems worthwhile right now) or scrap my editors (which, given the number of times they’ve saved my hide, seems to me to be the worst option).
HIMIPref™ Valuation for BCE.PR.C Suspect but Trading Engine Recovers
Monday, April 23rd, 2007I was asked in the comments for April 20 whether the valuation shown by HIMIPref™ for BCE.PR.C was OK or not … it was showing a massive, massive positive number.
Well, no, it wasn’t … it dropped out of the math as designed, but division by small numbers can cause problems and huge results. The trading engine knows that this sometimes happens, however, and annulled the result without recommending a trade.
The riskRewardAnalysisBox showed numbers that all looked fairly normal, with the exception of portYieldReversion: this showed an exceptionally – ridiculously – high value of 135.443.
Therefore, one looks at the riskRewardAnalyticalValuesBox to find that this value depends upon some reasonable reversion factors and a pseudoModifiedDurationPort of -244.2194 … rather a large value, and with a funny sign, to boot!
The calculation of this variable may be examined via the pseudoPortfolioReportBox, which reports that a 2% change in price results in an absolute yield (and we are talking about portYield, remember!) change of -0.0082% and the large value of pseudoModifiedDurationPort.
Bringing up the details for the three yield calculations implicit in this value, we find that the high priced yield is 4.1622% with a price of 23.937 and the base priced yield is 4.1702% with a price of 23.70 while the low priced yield is 4.1540% with a price of 23.463.
Essentially, what is happening is that the probability of a near-term call at a price higher than market is goes up with price at a rate that nearly exactly matches the decline in yield of the far more likely limitMaturity, so that price changes, at this particular price level, have a negligible effect on this particular measure of yield.
*sigh* It happens.
Fortunately, though, an occasional blow-up like this is accounted for in the trading engine – even at the ridiculously high valuation, there are very few trades generated into this security.
When we look at the trade evalation report, into BCE.PR.C out of a randomly chosen security, we see that the bidToOfferPickup is negative. Negative? How can it possibly be negative when the valuation on the buy side is so high?
To answer that, we look at the pickup calculation box for this trade and find that, while the buyValuationAsk is much greater than the sellValuationBid, there is a large negative contribution to the total pickup from the parameter excessRewardDifferenceValuation, a parameter invented for just such occasions.
In the standard parameterization supplied with HIMIPref™, the parameter excessValuationCap is set to 1.00, while the excessValuationReduction is set to 2.00. This adjustment – one might almost call it a sanity check in the calculations – prevents the trade from being shown as desirable, both in live reports and in future simulations that will analyze this date as part of the continuing efforts to refine the parameterization.
OK, so it’s maybe a little complex. So?
Connection Test for HIMIPref™
Friday, April 20th, 2007There are periodic problems with accessing HIMIPref™ over a network – problems that appear to flummox networking specialists. I know I’m flummoxed!
The problem arises from the length of time it takes to perform the calculations: in the full institutional version of HIMIPref™ all calculations are performed from scratch. It’s done this way because I want to provide massive amounts of intermediate data to clients for verification and explanatory purposes and it’s easier to produce all this stuff de novo than to write it to files then read it and transmit it separately.
Anyway, when logging in to HIMIPref™, you see notifications of fundamental data coming in (dividends, options …) then a wait screen while the calculations are performed. In some systems, particularly with proxy-servers, the system will hang as the client programme waits for data from the server that just ain’t coming. I never see this problem with direct connections.
Rather than endure any more speculation from network technicians that I just plain can’t write code, I have developed a Connection Test [Link updated 2024-3-22]. It uses the same technology as HIMIPref™ but just sleeps for input number of seconds and returns an integer vector of the input length (in case anybody suspects that the volume of data is a contributory factor).
Full source code is available to HIMIPref™ clients.
Update: A note regarding the availability of this test has been added to the HIMIPref™ documentation, “System Requirements“.
ALB.PR.A, LFE.PR.A Added to HIMIPref™ Universe
Sunday, April 15th, 2007The two issues in the title are split shares, both rated Pfd-2(low) and both with a high market capitalization.
They have been added to the HIMIPref™ database and will probably be added to the SplitShares Index on the next rebalancing, which will be at month-end.
RY.PR.G Splatters onto Market
Friday, April 27th, 2007The new issue of Royal Bank 4.5% perpetuals announced April 17 settled today and met a very poor reception, trading in a range of 24.48-60 and closing at 24.49-50, 20×12.
I’m at a bit of a loss to understand this and can only speculate that the continuing BCE debacle has caused a little nervousness amongst retail, while institutional buyers may be filled up on Royal after their string of new issues:
RY.PR.K is retractible – all the others are perps.
However, it might not matter a lot whether the market is fed up with the name or not! Examining the figures for Royal’s tier one capital limits, we see that they had room to issue preferred of $520-million on February 6 (after the issuances of RY.PR.C, RY.PR.D & RY.PR.E and redemption of RY.PR.O) and with the 18-million shares issued since then have used up $450-million of that. That leaves a mere $70-million in issuance room and they might not be willing to go to market for such a paltry amount.
Note I will admit that I am somewhat at a loss to reconcile their Preferred Share Tier One Capital of $1,345-million at year end with their list of issues outstanding. The figure of $1,345-million is referred to in the MD&A on page 66 of the Annual Report – this table contains no mention of any preferred shares in Tier Two Capital, which is where I would expect to find the retractible issue RY.PR.K. Note 18 on Page 130 of the Report shows $1,050-million perpetuals, and $298-million “Preferred Share Liabilities”, specifically including RY.PR.K (Series N). So I guess that, somehow or other, they were able to include RY.PR.K in Tier 1 Capital.
So, given that the RY.PR.O has been redeemed, their Tier One Capital preferred situation now looks like this:
All in all, they’re very close to their limit now, unless they boost their equity capital in other ways, like hiking ATM fees. But fear not! The RY.PR.K becomes redeemable at par 2007-08-24 (although not retractible by holders until 2008-8-24) and eliminating this issue with open up another $300-million of issuance room.
It is not my habit to include such an incomparable comparable as the BAM new issue, but I just couldn’t resist! BAM has a boatload of preferreds outstanding, and if we can blame overall market tone and angst for today’s RY.PR.G debacle, then the May 9 BAM settlement could prove interesting in the extreme.
The securityCode for RY.PR.G is A45016, replacing the preIssue code of P87500. A reorgDataEntry has been processed.
Posted in Data Changes, Issue Comments, Regulatory Capital | 4 Comments »