Archive for the ‘Documentation’ Category

LimitMaturity

Friday, April 15th, 2011

I use the phrase because preferred shares can last forever; but taking account of this infinite length of time would require too many special cases in the software and take up too much computation time for very limited benefits – if any! I made the point a few times in the appendix to the April, 2011, PrefLetter that if you calculate more decimal places than are justified by the accuracy of your data, then you are really just wasting time fooling yourself.

So, instead of performing special calculations to account for the preferred share lasting forever, the software instead defines “forever” as “thirty years from the date of calculation”.

Thus, for example, the recommended BAM.PR.N issue is denoted with a “LimitMaturity”, since the fact that it is trading at a discount to par with no means by which an investor can force the company to redeem them means that it is prudent to assume they will last forever.

In order to analyze these shares in a manner consistent with all the other issues, the software then pretends, on the calculation date of 2011-4-8, that the issue will mature on 2041-4-8 at a price equal to its current price of 21.10. This assists in the computation of Modified Duration and PseudoConvexity.

In turn, this ensures that the calculations, and the valuations, are consistent with the calculations and valuations for those issues that really do mature (such as BNA.PR.C, for instance) and the increase in comparability is worth the slight loss of accuracy.

TMX DataLinx: "Last" != "Close"

Tuesday, December 21st, 2010

Like the old man said … “If you go out and buy financial data and you assume something, you make an ASS out of U and ME both.”

Assiduous Readers will recall that on December 2 I reported a stupid quote for GWO.PR.J and indulged in a rant; I also sent a note of inquiry to the TSX:

According to information reported on TMXMoney.com for December 2, GWO.PR.J traded 2,831 shares in a range of 27.41-64 and the last of the eleven trades was at 3:33pm. The closing quote was 24.81-27.54, 4×9.

I have four questions that arise from the closing quotation:

i) Who is the market-maker for this security?

ii) Will the TMX be investigating the circumstances that led to this ridiculous closing quote?

iii) Will the TMX be announcing the results of such an investigation?

iv) Will the TMX be implementing any sanctions against the market maker for this security?

I eventually received a reply:

A closing quote is considered to be the quote at the close of the regular trading session at 4pm. Market Maker responsibilities end at 4pm. The actual closing quote at 4pm on Dec.2 for this issue was 27.04 – 27.54.

After frothing at the mouth a bit, I sent the following eMail to my data provider, TMX DataLinx, who get a fat cheque every month for providing me with data:

As you will be aware, I have been a purchaser of your historical data for about ten years; and was a customer prior to then through my previous employer, Greydanus Boeckh & Associates Inc.

Amongst the data I purchase from you are the “last bid price” and the “last ask price”.

On December 2, 2010, you reported to me that these values were 24.81 and 27.54 for GWO.PR.J.

An inquiry to the exchange regarding this quote elicited the information that “A closing quote is considered to be the quote at the close of the regular trading session at 4pm. Market Maker responsibilities end at 4pm. The actual closing quote at 4pm on Dec.2 for this issue was 27.04 – 27.54.” as shown in the forwarded eMail, below.

(i) What is the difference between the data you have been selling me and the “closing quote”?

(ii) How may I purchase the “closing quote” from you?

Finally, after a fair number of reminders, a few telephone conversations and a conference call, I have sent the following eMail to the Product Manager at TMX DataLinx:

I write to you to request a new product be made available for data download through your “TMX DataLinx Market Data” facility.

This product would be accessed by entering the password-protected page http://marketdata.tsx.com/MOTD/ clicking “Custom Queries”, “New Query” and “Stock Prices” (or, after the first run, via “Saved Queries”).

Options for “Closing Bid” and “Closing Ask” would be added to the list of “Data Items”.

These data would provide the last quotation of the day at which one board lot of the security in question could be transacted; i.e. a snapshot of the market quotation immediately before the close of the regular trading session.

They would be distinct from the extant “Last Bid” and “Last Ask” data items currently available, since these two items represent the quotation at the end of the extended trading session. They will not necessarily reflect the market quotation at the close of the regular trading session since:
(i) Orders in the book at the close of the regular trading session may have been cancelled in the interim
(ii) Orders entered in the interim will not be included in the book unless they are at the Last Sale Price; they will be rejected by the Exchange.

It has been suggested that I could recover these data by clicking “Trades and Quotes” instead of “Custom Queries” and downloading the file for a period of time near the close. The “Closing Bid” and “Closing Ask” could then be determined through inspection of the downloaded data.

Such a solution is not practical because:
(i) Time resolution in this facility is limited to increments of one minute. There could, conceivably, be thousands of quotes for each security during this time frame and the cost of these data could be enormous
(ii) Data will only be recovered if the quote changes during the specified time. Thus, for some subset of the security list not known in advance, a prior time increment would need to be queried, which, in addition to being time consuming, would still bring with it the risk of enormous cost as specified in objection (i).

Therefore, I request that the “Closing Bid” and “Closing Ask”, which would together comprise the last quotation of the day at which an investor could execute at least one board lot on either side during the regular trading session, be made available as downloadable data under the same terms and conditions as your extant “Last Bid” and “Last Ask” data items.

I venture to suggest that most purchasers of the “Last Bid” and “Last Ask” data (including myself, until recently!) are under the impression that they are, in fact, purchasing the “Closing Bid” and “Closing Ask”. If you should find a customer who is not only aware of the difference, but prefers the “Last Bid” and “Last Ask” data, I would very much appreciate it if you could ask him to call me (416 604 4204) and explain, since I can see no possible use for these items which do not necessarily represent actionable bids and offers.

Prior correspondene on this issue is appended to this eMail

I don’t think I’m the only one who does not appreciate the difference between “Last” and “Close”; this is particularly important at this time of the year, when funds are required to provide a reconciliation between their normal method of reporting NAV and the new standards, as elucidated in the 2009 Financial Statements for PIC:

Net Assets per unit is the difference between the aggregate value of the assets of the Fund and the aggregate value of the liabilities excluding Preferred shares of the Fund on that date and including the valuation of securities at bid prices divided by the number of units then outstanding. For years prior to 2007, securities were valued at closing prices. The change to the use of bid prices is due to accounting standards set out by the Canadian Institute of Chartered Accountants adopted November 1, 2007 relating to Financial Instruments.

The Fund has adopted, effective November 1, 2008, Canadian Institute of Chartered Accountants (“CICA”) amendments to Handbook Section 3862, “Financial Instruments – Disclosures”. The revised disclosure requirements are intended to improve disclosures about fair value and liquidity risk. The amendments establish a three-tier hierarchy as a framework for disclosing fair value based on inputs used to value the Fund’s investments. The hierarchy of inputs is summarized below: (1) Level 1 – for unadjusted quoted prices in active markets for identical assets or liabilities

Securities are valued at fair value, which is determined by the closing bid price on the recognized stock exchange on which the securities are listed or principally traded. If no bid prices are available, the securities are valued at the closing sale price.

These rules have been discussed by Price-Waterhouse.

Naturally, it may be that I am the only investment manager in the world to have made this error. But, given the ubiquitous nature of the “Last Bid” and “Last Ask” on the web (fed to QuoteStream, for instance, which republishes it on the TSX’s own TMX Money website), I’ll bet I have lots of company.

Fortunately, this can only have a positive effect on the presumed efficiency of the HIMIPref™ simulations, which define the parameterization of the analytics; the programme sells at the presumed bid and buys at the offer; in nearly all cases the “Last” will be worse than the “Close” – the only exception will be when the Last Sale Price is the bid (ask) at the close and becomes the ask (bid) at the end of the extended session. Thus, simulations may have executed notional trades at worse prices than those actually available, or have missed opportunities; both of which will have resulted in underestimation of the value of the analytics.

For your further reading pleasure, here are some extracts from the TSX Trading Rules:

Rule 4-901 states:

Rule 4-901 General Provisions (Amended)
(1) All listed securities shall be eligible for trading during the Special Trading Session, provided that a MOC Security shall not be eligible for trading until the completion of the Closing Call in respect of that MOC Security.
(2) Except as otherwise provided, all transactions in the Special Trading Session shall be at the Last Sale Price for each security.
(3) Except as otherwise provided, the normal rules of priority and allocation and all other Exchange Requirements shall apply to the Special Trading Session.

Amended (March 29, 2004)

Rule 1-101 states:

“Last Sale Price” means:
(a) in respect of a MOC Security, the calculated closing price; and
(b) in respect of any other listed security, the last board lot sale price of the security on the Exchange in the Regular Session.
Amended (March 10, 2006)

Update, 2010-12-23: I do not believe that the extended session (whence the “last bid” and “last ask” quotes are obtained) meets the CICA definition of an active market:

[CICA Handbook] Para. 3855.A44. “A financial instrument is regarded as quoted in an active market when quoted prices are readily and regularly available from an exchange, dealer, broker, industry group, pricing service or regulatory agency, and those prices reflect actual and regularly occurring market transactions on an arm’s length basis. Fair value is defined in terms of a price agreed upon by a willing buyer and a willing seller in an arm’s length transaction. The objective of determining fair value for an instrument that is traded in an active market is to arrive at the price at which a transaction would occur at the balance sheet date in that instrument (i.e., without repackaging the instrument) in the most advantageous active market for that instrument to which the entity has immediate access. The existence of published price quotations in an active market is the best evidence of fair value, and when they exist they are used to measure the financial asset or financial liability.”

The “last” quotes do not reflect “actual and regularly occurring” (or even possible) market transactions, since any transactions in the extended session must occur at the Last Sale Price.

Update, 2023-10-25: See the posts More on the TMX Close != Last and TMX to Report Closing Quotes … Someday for more information.

What is the Yield on BCE.PR.Y?

Tuesday, December 16th, 2008

I was recently taken to task for a claim that the yield on BCE.PR.Y was 8.18% based on a dividend of $1.05715 and an end value of $25.00 – my correspondent stated – quite rightly – that:

the most recent monthly dividend, declared Oct 28, 2008, was $0.8333 or $1.00 per year. Also Prime has dropped to 3.5% from 4% earlier this month, (according to the BOC website), indicating a further cut in the dividend in the near future. Even at the rates and prices you quote I make the yield out to be 7.3%.

My defense is as follows:

They system estimates the average future rate of prime by looking at the past. If we stay at 3.5% prime for long enough, the estimated future rate will drop to this level, but for now it’s higher.

Additionally, the system estimates the end-value (a “limitMaturity” is treated as thirty years, remember) by determining the price at which the instrument is fairly valued; determining fairness by comparison with other floating-rate dependent issues. This was the result of some experimentation and proved to be a better predictor than assuming a constant price (as is done with fixed-rate perpetuals).

Basically, the assumption is that an Investment Grade issue will not pay 100% of prime forever. There will be shocks, of course, and every now and then such an issue will be downgraded and quite properly pay 100% of prime; but over the long term such a rate is not sustainable.

I will admit that this analytical framework was formulated when deviations were relatively small; an investment grade issue paying (25.00 / 14.25) = 175% of prime is not something that happens often enough to permit testing!

All the above is not very satisfactory, I know: but there are a lot of moving parts in the analysis of these ratchet rate issues and the framework was determined empirically. In some cases, to my chagrin, the results are not even internally consistent (e.g., I might be estimating a ratchet yield of less than 100% of prime with end values well below par).

All I can say is that the empirically derived system, while having theoretical holes in it, does have a statistical ability to rank the various issues with significantly better-than-random accuracy, which is all I ever wanted it to do.

Now lets do the cash flow analysis! I have uploaded the full HIMIPref™ output; the last part is:

2038-12-16 MATURITY 25.00 0.080242 2.01

Total Cash Flows 56.6052
Total Present Value 13.5028
Discounting Rate 8.5887 % (Annual rate compounded semi-annually)

So for starters, we see that the the discounted present value of the $25.00 maturity is only $2.01. It’s not a particularly important variable.

But compare four bonds priced at par, each one paying $12 p.a., but with differing frequencies (annual, semi-annual, quarterly, monthly). Each one is described by fixed income convention as having a yield-to-maturity of 12%. Which would you rather have? Obviously, the monthly payer, since then you get your money faster … and this is borne out when we look at the annualized internal rate of return for the four bonds: 12.00%, 12.36%, 12.55% and 12.69%, respectively. The limiting case is an infinite number of infinitesimally small payments totalling $12 and has an IRR of exp(0.12) – 1 = 12.75%.

We note from the HIMIPref™ report that the 30-year discounting factor is 0.080242 so
1 / (1 + I)^30 = 0.080242
(1 + I)^30 = 1 / 0.080242 = 12.4623
I = 8.7727%

To convert this annual value to semi-annual, bond-equivalent yield, we note:
1+I = (1+i)*(1+i)
(1+i) = 1.042942
i = 4.2942
and therefore, the bond-equivalent yield is 2*i = 8.5884%, which is slightly different from the quoted figure, but we’ll attribute that to rounding.

But how to calculate this ourselves? The “ratchet yield” is 4.1997% of par, which implies total payments of $1.049925. These are made monthly, so monthly payments are $0.087494, which has been shown as a rounded value of $0.09 in the HIMIPref™ report.

The normal quick-n-dirty calculation is:
i = [Annual Income + Annual Capital Gain]/[Average of Beginning and Ending Price]
Annual Income = oh hell, let’s just call it $1.05, shall we?
Annual Capital Gain = Total Capital Gain / Term = (25.00 – 13.50) / 30 = $0.38333
Average of Beginning and Ending Price = (25.00 + 13.50) / 2 = 19.25

resulting in a quick-n-dirty estimate of (1.05 + 0.3833) / 19.25 = 7.45%.

It’s a lousy estimate. Terrible. Why?

Mainly because the beginning and ending prices are so different. The calculation assumes that the capital gain is realized in a linear fashion … but in fact, if it accrues at a constant rate, nearly twice as much is accruing at the end of the period as at the beginning. Conversely, the $1.05 income is much more interesting at the beginning of the period (current yield = 1.05 / 13.50 = 7.78%) than at the end (current yield = 1.05 / 25 = 4.20%.

When the capital gain through the period is massive, simple methods become simplistic. Such is life! Fortunately, yield calculators and Excel Spreadsheets will be readily available to most people.

Related discussions may be found in the posts regarding Research: Modified Duration and Research: Yield from on-line Calculator.

Listen, take it from an old bond guy: if anybody ever tells you yield is simple, don’t listen to him!

Connection Test for HIMIPref™

Friday, April 20th, 2007

There 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. 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“.

HIMIPref™ Documentation : Trade Document

Sunday, February 4th, 2007

The section of the User Manual dealing with tradeDocument has been improved.

There is now a section dealing specifically with the portfolioMethod and the multipleTradeReportBox.

HIMIPref™ Documentation : Editing Portfolio Constraints

Thursday, February 1st, 2007

Another page has been added to the HIMIPref™ User Manual : Editing Portfolio Constraints.

This page provides step-by-step instruction on what to do if you don’t like your portfolio’s constraintSpecificationRecord.

HIMIPref™ Documentation : PortfolioInputBox

Thursday, February 1st, 2007

The user manual page portfolioInputBox has been upgraded slightly … there was a problem in which the programme appeared to be frozen, but – as far as I can make out – the commissionInputBox was not visible, although it was expecting input. The visible commissionReportBox was not accepting input.

Should such a thing happen, the commissionReportBox should simply be moved to another area of the monitor screen. The commissionInputBox will then be visible AND accepting input.

Documentation : Analytical Universe Selection

Tuesday, January 23rd, 2007

Drew’s comments and queries have, as always, pointed out some deficiencies and, as is not quite so often the case, have led to an improvement in my documentation.

There is a new page in the User Manual: Analytical Universe, that basically restates my responses to the original query. Please – don’t be shy about asking questions and telling me that something’s not clear! I’ll always listen – it’s getting me to do anything useful that’s hard!

User Manual : Deleting Account & Deleting Transaction

Thursday, January 18th, 2007

Some documentation has been added to the user manual on the captioned issues: