Posted by Peter Orr on Thu, Aug 19, 2010 @ 12:10 PM
With rates this low, how much time and money are you spending running and re-running refunding numbers for your issuer clients and targets? This is an expensive, labor intensive, manual task that is far more accurately, predictably, and cost-effectively done across the department through use of a robust database solution that emails results to the banker, advisor, or issuer.
If you have no idea how much time and money is spent performing these tasks, they likely are costing you way too much. After all, what gets measured gets managed…
Posted by Peter Orr on Thu, Apr 01, 2010 @ 03:44 PM
It's 2010 and time to raise the bar. Public finance software has remained substantially unchanged for over a decade, and probably more like two. In this day and age your public finance software, in addition to all the other stuff it's done since TRA86, must add the following five features:
1. Reflect Uncertainty and Quantify Risk
Because so much brainspace is bogged down in satisfying tax rules coupled with analysts' difficulty implement models outside the ubiquitous spreadsheet, public finance analytics tend to force single point forecasts for market elements: variable rates, SIFMA/LIBOR ratios, VRDN support costs, etc. What does this mean? It means uncertainty is modeled with certainty which today borders on the absurd and exacerbates our species' now well documented tendency towards overconfidence. Your public finance software needs to at least provide for the identification of cash flow risks and their modeling in a straightforward, efficient way.
2. Visual Interaction with the Problem
Have you seen a video game made any time in the last 5 years? These are true technological achievements. What fraction of the computing power going into a video game rendering the bad guy around the corner finds its way to helping you visualize the complex financial decisions you or your clients make? 0.1%? 1% maybe? Let's raise the bar - make it 10% and let's see what that looks like. Unless you're able to quickly get a visual read of the problem and interact with it visually (move revenue lines, modify risk constraints, etc) your public finance analytics need a makeover.
3. Calculate Solutions Subject to Explicit Risk Constraints
Public finance analytics that solve for the minimum bond size achieving an overall expected debt service shape, wrapping around existing bonds and derivatives as applicable, while also measuring additional marginal risk contribution are now just a baseline. Public finance analytics in 2010 must also allow the user to enter an explicit risk constraint to which the solution is bound. In this way, the user sees the most cost effective, risk-adjusted solution determined from multiple financing sources on a maturity by maturity basis.
4. Accommodate Swaps and Other Derivatives
Tax-exempt variable rate bonds aren't going away any time soon. Therefore and despite some reporters confusion over what "speculation" is, interest rate swaps, caps, and collars probably aren't going away either. If your public finance software doesn't analyze these very non-trivial instruments in very non-trivial ways, you're missing a very big part of the financial analysis for you or your clients.
5. Include Refunded Bond Selection as Integral to Solution
Selecting what bonds to refund isn't always as simple as firing up your refunding screen and grabbing everything above 3% pv savings. A number of interrelated factors go into determining the marginal contribution that an additional refunded bond has to the economics of a refunding. Your public finance analytics should rise to the challenge.
If you're an issuer, the features above offer you a deeper understanding of what's going on with your capital structure. This makes you a far more knowledgeable consumer of banking and advisory services. If you're a pubfin banker or advisor, these features are a pre-requisite to demonstrating you understand your clients.
The world is changing fast... and public finance is no exception.
Posted by Peter Orr on Wed, Mar 24, 2010 @ 12:29 PM
Lots has been studied and even reported on the decision criteria involved in pulling the trigger on a public finance refunding. When is the right time? What bonds do I choose? What savings target do I use? The old rule of thumb that present value (pv) savings should be at least 3% of refunded par is taking some criticism which I won't repeat here. Suffice it to say it's a threshold originally conceived by bankers and as such, the bar for a "Go" decision is not very high. I personally think it's age discrimination; this calculation does have a good three decades under the belt...
One proposed alternative is to look at something called "refunding efficiency." This involves taking the pv refunding savings on a transaction and dividing by the theoretical value of the refunding option. The closer refunding efficiency is to 100% the better. Without going into free boundary problems and other option exercise minutiae, suffice it to say that coming up with a reasonable hypothetical value of the optional redemption feature in a bond issue is no simple task. It's not as easy as just valuing the bond option using Hull-White, BDT or other fixed income model. The issuer's refunding option can involve interrelationships between taxable escrow security prices and tax-exempt bond market volatility at different points on the yield curve that, along with tax-exempt bond vol itself, inevitably lead to unobservable (read "anyone's guess") inputs.
And here's where the logic flaw often resides. Just because refunding efficiency on a deal is calculated, based upon the aforementioned heroic assumptions, to be 80% refunding efficient does not mean the issuer has somehow left the other 20% of value on the table somewhere. There is no practical way to capture that 20%. It is a purely hypothetical number. Even stripping the option and selling it doesn't replicate the economics the issuer faces (plus can have real pain-in-the-neck tax consequences).
I'm not saying this refunding efficiency metric is useless. I am saying that it should be interpreted very carefully: refunding efficiency is a comparative way to see the likelihood that refunding savings might be higher at a later time. It is a measure of possible opportunity cost. Looked at this way, it is debatable even whether market implied parameters are the right ones to use in pricing the refunding option. Applying forward rates and implied volatilities willy nilly to every financial model that needs an input is a mistake all too often made by analysts buying too much into their own quantitative hype, and usually trying to sell something. I'll leave this to explore more fully in another post, but suffice it to say that it is absolutely incorrect to estimate real world (as opposed to "risk-neutral") probability densities or forecasts using market-implied parameters.
So if refunding efficiency is not the holy grail of refunding decision analysis, and it's just a way to get a sense for the opportunity loss involved in pulling the refunding trigger, then the issuer is still left with a fundamental and not easy risk management decision. A bird (pv savings) in the hand is worth how many in the proverbial bush? This is a classic utility preference problem whose answer will differ depending upon the views, needs, and circumstances of the issuer. No absolute rule of thumb (95%, 85%) will ever be applicable to every issuer or every situation.
Often the credibility of a certain mode of analysis is directly correlated to the perceived sophistication involved. In fact, often the exact opposite approach should apply - the fancier the model, the more skepticism it should face about the assumptions embedded in it.
I think we all should be very careful of holy grail quantitative metrics, particularly if they have the danger of becoming a new "industry best practice." Regulators, under the guise of wanting to adopt "industry best practice," incorporated various Value at Risk (VaR) concepts in their rules. Over the last 18 months, I hope we learned that applying a one-size-fits-all number to complicated risk management problems without fully understanding the assumptions and limits can be very, uh... risky.