How Many Refunding Opportunities are You Missing?

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… 

Financial Software: The answer to “Build or Buy?”

"Programming today is a race between software engineers stirring to build bigger and better idiot-proof programs, and the universe trying to produce bigger and better idiots. So far, the universe is winning."            - Unknown

Many public finance businesses are grappling with the "build vs buy" question as it relates to their analytic tools.  I've commented here on the challenges of building good

 financial software and frankly, most firms that aren't specifically in software development are poorly equipped to do so.  And this is a tangentially related and important question.

Of course, build vs buy is not a new question generally but it may be new to some in financial services. The most succinct variant of the common wisdom on this is in this infoworld article . Here's the bottom line from the article:

"Decades of trial, error, and egghead analysis have yielded a consensus conclusion: Buy when you need to automate commodity business processes; build when you're dealing with the core processes that differentiate your company."

There's an interesting dynamic about the technology "backbone" behind a public finance business (providing accurate/current debt profiling, refund screens, historic prices and reset histories from EMMA, bond and option valuation functionality, etc).  Although these may be commodity business processes that every banking/advisory/investment firm must do in one form or another, that data backbone serves as the foundation for proprietary analytic tools and reports that can differentiate one from the rest. 

At IA, we do both automation and innovation so that the workflow public finance analytics need to support are fully addressed. This allows us to be far more efficient and effective in designing each.    

Other good "build vs buy" articles here:

techrepublic 

MIT Free Software: Build or Buy Dilemma 

Top 5 Things Your Public Finance Software Must (now) Do

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.     

The Big BAD Mistake about BABs

"Prediction is very difficult, especially if it's about the future." 

- Niels Bohr (long before Yogi Berra) 

Lots of people seem to be making a big mistake analyzing Build America Bonds (BABs).  The popular and straightforward analysis is to compare yields on traditional fixed rate bonds (or "BOBs" as I call them - Boring Old Bonds) to the after-subsidy yield on BABs.  Here's an example:

 

The (overly) simple analysis says that BOBs are the cheaper cost of capital through about year 12 and then BABs are the way to go thereafter.

The heroic simplifying assumption of course that works so nicely in spreadsheets and standard software packages is that this line-item Federal subsidy duck will stay staticand not shot down over the entire life of the bonds.  Is this a good assumption?   Let's look at some facts:

-     The BABs legislation explicitly states that the subsidy is not permanent and can be changed at any time

-     The BABs subsidy is qualitatively very different than the one inherent in BOBs.  As anyone dealing with a government budget knows, there's a fundamental practical and political difference between revenue lost in the opportunity sense (BOBs) vs the Treasury needing to cut a check for a subsidy as with BABs  

-     The US debt and fiscal imbalance are ugly. Some argue worse than they've been excluding WWII

With these facts, is it prudent to be overly optimistic about this US subsidy staying static over 20-30 years, through changing administrations, congressional seats and political winds?  I don't think so.  In fact, the analysis of this risk is not unlike the oft-discussed "tax risk" that people cogitated about when evaluating synthetic fixed-rate borrowing strategies using LIBOR swaps.

Putting a finer point on it, when an issuer sells BOBs the following risks are shifted to the investor:

1)   Interest rate - rates go through the moon, the investor suffers the MTM loss. The nominal cost of capital for the issuer is locked in.

2)   Credit - should the issuer's credit deteriorate, again the investor suffers

3)   Tax law - should the US become less reliant on income taxes and more on consumption taxes or VAT or shifts to a flat tax, the preference for tax-exempt income would fall and investors would suffer losses.     

For BABs, the third item no longer applies.  The investor gets a taxable coupon.  Has the third risk gone away entirely?  I think it's been transformed.  That third "tax law" risk is now replaced with US Fiscal Policy Risk (FP Risk^TM) which I would argue is significantly non-zero and different qualitatively then we've seen before in the tax-exempt markets.   

So if we're NOT to assume that this subsidy will stay static, and now the issuer has this new FP Risk to manage, how can this risk be incorporated into decision-metrics in a non-trivial way?  After all, what gets measured gets managed.  Stay tuned, but in the meantime, what do youthink?